Providing a Driver for printing to screen

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
Warrior

Providing a Driver for printing to screen

Post by Warrior »

I'm attempting to write a video driver but want to know how I would go about doing certain things.


- Should the user be able to scroll up the screen and see previous text?

- Should the user be able to type behind is starting point? (if they scroll back)

I was thinking store the X/Y values of the users starting point when they first print text and reset it everytime enter is pressed. I don't want my users overwriting information the kernel has printed but I want to maintain the ability to scroll back.

As for scrolling up after the text is gone, I figured once the maximum Y has been reached on the screen, store everything that's currently on the screen somewhere. Question is how will I know if the user has scrolled up past the new starting point so I can store that and rewrite the old?

I guess my aims are to have an console enviroment where the user can see whats happened if it happens as a rapid rate (as it sometimes does in linux =P and iirc you can't scroll up)

Any comments are welcome.

Regards,
Warrior
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:Providing a Driver for printing to screen

Post by Pype.Clicker »

you can certainly scroll up in most linux consoles. The only thing is that the "scrollup" is limited to a certain amount of line ... and that framebuffered consoles may lose the "content of what's scrolled up" when you switch to X.

about "continueing to type" while scrolling, most common approach is to jump back to the current write position when typing (which i found myself highly irritating). I'd instead suggest you _split_ the output in that case, higher half showing what's being scrolled and lower part what's being typed.
Warrior

Re:Providing a Driver for printing to screen

Post by Warrior »

Ah, don't know much about linux, made a guess from the little times I've used it.

That's a pretty good idea, thanks.
Warrior

Re:Providing a Driver for printing to screen

Post by Warrior »

*bump*

Any ideas on how to stop a user from overwriting important messages? Possibly only go back as far as he typed?
AR

Re:Providing a Driver for printing to screen

Post by AR »

What are you talking about exactly? No, the user should not be able to type behind the prompt as it would be pointless since nothing is going to read the input.
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:

Re:Providing a Driver for printing to screen

Post by Pype.Clicker »

Warrior wrote: Any ideas on how to stop a user from overwriting important messages?
uh ? could you detail how you imagine that could occur ? honestly, i don't get wwhat you mean ...
Warrior

Re:Providing a Driver for printing to screen

Post by Warrior »

Well my driver allows users to go backwards in thier position on the screen (for backspace) but they can overwrite messages that the kernel posted (error/success messages, status messages, etc..) I was just asking for thoughts on an effective way to stop this. The only thing that comes to mind is to save all text somewhere with an additional attribute (R/W) or another thought might be to only allow the user to backspace as much as he typed.
AR

Re:Providing a Driver for printing to screen

Post by AR »

You would probably want to record the XY coordinates that the prompt started at and ignore attempts to backspace behind that point.
Warrior

Re:Providing a Driver for printing to screen

Post by Warrior »

Yep, that seems the cleanest way to do it was just wondering if others did it differently. Thanks!
User avatar
bubach
Member
Member
Posts: 1223
Joined: Sat Oct 23, 2004 11:00 pm
Location: Sweden
Contact:

Re:Providing a Driver for printing to screen

Post by bubach »

AR wrote: You would probably want to record the XY coordinates that the prompt started at and ignore attempts to backspace behind that point.
The X and Y coordinates of the prompt can change if for example the typed command makes the screen scroll.
Keep track of the position in the input buffer and then check so that the buffer pointer is > 0 before doing the actuall backspace.

/ Christoffer
"Simplicity is the ultimate sophistication."
http://bos.asmhackers.net/ - GitHub
Post Reply