Viedo & Mouse Driver

[zack]

So. I resolved the malloc / free problem.
No i'm trying to develop a gui.

I setup a double buffer wich has the sam size like the screen.
each window has his own bitmap. so i musst not draw ever times the window new. the i memcpy the windows to the double buffer and after that i write the hole buffer to the screen (memcpy).
i reprogrammed the pic to 100hz and ever irq0 i update the screen.

this works good, slow but it works...

now my question is this a good idea?
could it be that it do not more handle keyboards / mouse events because it has to much to do whit copying. when irq0 is running all other interrupts are disabled? how can i correct it..

thank really.. sorry for this much questions..

[Solar]

So. I resolved the malloc / free problem.
No i'm trying to develop a gui.

...

now my question is this a good idea?

No.

But that is just me. I wouldn't jump to GUI code unless the basics (that includes e.g. application loading, shared libraries, inter-process communication, etc.) are all firmly in place already.

when irq0 is running all other interrupts are disabled? how can i correct it..

Ahem. Application loading, shared libraries, IPC, interrupt handling...

I know it is tempting to see some GUI stuff as quickly as possible if you are out for the "I did it". If you want the whole thing to really work, you should spend more time on the basic foundation.

That being said, there are good books available on how X Window works internally. Not that it is a work of brilliance, but it can give you the right ideas.

[OZ]

Hi,
you're trying to do the following - hacking some sort of basic gui code and putting it into an interrupt service routine.

Now if your hooking the PIT - set at 100 HZ - isr and do the whole gui with it you will have a gui, but it won't work as expected for several reasons.

First of all Interrupts can't be interrupted themselves therefore each interrupt stands in queue unless it's predecessor has finished. Therefore depending on how fast your code is - in fact it will never be fast enough to realize a whole gui in an isr which does not delay the systems response time to user input (another interrupt which must wait until whole screen got repainted and so on)
ISRs should be lightning fast and contain no code that is not neccessary to respond to the hardware which caused it.

Next thing is normally the PIT is used to archieve a timer which causes the task switching in a multitasking environment.
This is time critical meaning apart from the hardware the handler code is responsive for how fast the system will run with multitasking. If you ever want to implement multitasking it won't make sense to have very much gui code in the isr which has to be executed every time right before any task switch occurs.
With your design so far you only way to control how much cpu time the gui gets is changing the frequency of the PIT.
Well you could archieve the first 'extremely interrupted monotasking system with interrupt gui' but I guess that's not what you wanted.

Basically if you wanted to code that gui to be useable meaning
reacting to user input etc. you will have to implement multitasking first so that you can have a process providing the gui, while interrups can be used (as intended) for servicing user input without delay.

hope it helps

[distantvoices]

You don't need to update the screen every second. The video card does that by itself.

You are not to use interrupts for such lenghty tasks as updating windows. Drawing stuff shall be done either by a service or by a library (which gets clipping info from a service)

YOu shall not keep a buffer PER window. That's ... memory wasting:
Set aside a double buffer region inside kernel or service, and have this double buffer region be shared memory.

Have the window-loopers fetch clipping info on each redraw event() - especially issued b< services/kernel if screen layout has changed - else they'd draw by themself what needs to be drawn - and have them draw to the offscreen buffer - and from that offscreen buffer update the affected region.

Hope this helps.

stay safe.

[bluecode]

Set aside a double buffer region inside kernel or service, and have this double buffer region be shared memory.

Have the window-loopers fetch clipping info on each redraw event() - especially issued b< services/kernel if screen layout has changed - else they'd draw by themself what needs to be drawn - and have them draw to the offscreen buffer - and from that offscreen buffer update the affected region.

How do you prevent applications from just drawing all over your offscreen buffer, because it's shared memory and every application can access the whole buffer, or am I missing something here?

[zack]

yeah. paging as example. just must map the videomem to the application..
greez

[Warrior]

Why not keep the Drawing of Windows upto a "GUI Server" in the kernel?
It would maybe eliminate the problem of having the video memory shared and each application drawing directly to the memory.
Also that way the GUI can manage the offscreen buffer among other things.

[bluecode]

yeah. paging as example. just must map the videomem to the application..

I didn't miss ( ;D ) paging, nah. But if you share the whole offscreen buffer/the whole video memory with an application it can just draw _somewhere_ in that buffer and perhaps _somewhere_ you don't want that application to draw to!

@Nelson: Would be slower, but imho it's better that exposing the whole video screen to any application.

[B.E]

Make a Libary for the drawing of a windows and only allow applications to use the libary to draw to the windows. When drawing, first test to see if the pixel being drawn will be seen and if so update that pixel draw the pixel. if it is not seen don't draw it to the screen. When the window is moved. send a message to the application that is need to redraw.

drawing the mouse pointer: When the mouse is moved, restore the pixels at the current mouses location. store the pixel at the new location and draw the mouse pointer.