OSDev.org

Hi, fellas!

Just thinking about this: In the micro kernel environment, there are many possibilities to *pipe* data in a very quick manner hither and tither.

Now, I wanna redo my GUI service-Video Driver cooperation. It is awfully slow at the moment and in no case suitable for any environment. Why: because I have shied away too long from mapping the frame buffer memory into the gui service adress space.

In this scheme of things, the video driver wouldn't have to do anymore anything with drawing. Instead, it just would expose the frame buffer as a device for further use.

Now, another thing arises from there: drawing the mouse and handling the events. Till now, I am doing the mouse drawing and window moving in the video driver. I don't think this is good, because this way, the video driver hogs the cpu for quite some time.

I am thinking about stuffing mouse and keyboard events in form of packets into a kind of serial queue the gui service registers in kernel land. a thread of the gui service shall then pick up one packet after an other and perform the requested action.

What do you think about this? Is it rubbish?

Stay safe.

... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image

well, the design i would suggest would be to have the mouse and keyboard listened by the microkernel itself (i mean, responding to the IRQs, extracting data from the 8042 chip and pushing them in a FIFO towards the 'listener' service, whatever it is)

the GUI service would be responsible for reading those FIFOs (it could get notified of data presence by the kernel), perform further decoding like translating the mouse packet into some X,Y + buttons events and the keyboard packet into some unicode character or a 'special keystroke', inspect the 'current window' preference and events masks, and if needed, send the datum to the responsible GUI client ...

If i had to do it myself, i would rather have the 'video' driver as a shareable component that can be 'imported' in the GUI service. For instance, the video driver may have hardware cursor feature which is only supposed to be used by the GUI service, but it may occur that another video driver has no such support, so it only exports a software rendering library instead...

Once the driver has been 'imported' by a client, though, no other client can connect to it, and such an 'import' is only achievable when the driver has no client ...

Image May the source be with you.

The question of seperation of GUI and Messaging has always been interesting.

On one hand a well defined API allows applications to access all gui services under gui control, but lacks flexibility and as you've pointed out speed.

On the other, simply whacking up a linear section of memory as a virtual screen gives all sorts of flexibility but at the price of everything being done in software.

Discarding (most) hardware acceleration for the moment, the only thing a video driver should be concerned with is, "here is a bunch of windows draw them".
For standard 2D windows you're stuck with slowness. Apart from a bit of block move acceleration, don't expect anything more from any video card.
For 3D windows, these can be drawn using hardware acceleration by feeding the display list generated by your vector engine to the video driver. The driver then calls the hardware accelerator to draw the triangles, textures etc. at full speed.
If you're stuck with software rendering then it should be done before reaching the video driver. Then all output can be done by 2D objects (lines make triangles, flood or pattern fill triangles).

Separating your graphics into a pipeline like this can speed up your graphics (2D and 3D) just like pipelining in the 486 made it four times faster than a 386 at the same clock speed (I don't guarantee that kind of increase though!). Pipelining can also be veiwed as micro-kernel versus monolithinc. Splitting the problems into components should prove useful and make life less complicsated..

Many good books are available (Andrew LaMoth's 3D game programming series is recommeded, make sure it's DOS based though - it's easier to port). Although you might not be writing games, the principles are developed here for fast graphics pipelines in software.

As for messaging, the mouse cursor is just a small transparent window - where is goes on the screen is of no business to applications. Update it with information received from the mouse and then send the data onto the appropriate application.
Then draw the mouse as a normal window, or if you can access the hardware cursor, use that (I'm not sure how you can animate it or do fancy happy user stuff though.)
Anyway - I'd recommend removing it from the video driver into it's own little interrupt handler (small, neat and single minded - get mouse packet, update mouse cursor location, pass on mouse packet, IRET).

As for the shareable component bit - the more components the better. By limiting the things the driver can actually do, you should be able to make it 'upgradeable on the fly'.
(Stop component, export start of display list, copy new pointers to new driver, import start of display list, restart new service).
Nothing more annoying than "Reboot system, for driver to take effect" Errrrr <:(.

Messaging: following on from above, the only message the video driver should receive is a list of windows and their starting addresses. You can do window sorting and Z-buffering before sending to the video driver. Anything that hasn't been updated can be removed from the sorted list reducing the work of your video driver even further. Application windows can exist in the 'plane' (in the video cards memory) or across the 'plane' (stored in main memory).
In the plane is faster because you can get the viseo card to do it, but there is never enough video memory for all windows. (Especially for textures).


Messaging from applications to the GUI/S is a totally different proposition but I hope my suggestions can help you get some more speed.

First, thanks for the suggestions! :-)) Appreciating them!

What about exposing a frame buffer device to the gui service and having the gui service doing all the drawing onto the frame buffer directly?

Further, what about informing the gui service about a mouse event via a signal sent by the mouse driver? The according signal handler would then kick off the mouse handling in the gui service which fetches mouse packets and does what it has to do?

Things to think about...

STay safe, and thanks!

... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image

beyond infinity wrote: First, thanks for the suggestions! :-)) Appreciating them!

What about exposing a frame buffer device to the gui service and having the gui service doing all the drawing onto the frame buffer directly?

That way, you would prevent yourself from using any acceleration beyond the simple framebuffer.

What i would use as 'video driver interface' would be: If all the "hardware" can offer is a flat screen buffer, you'll have functions that will, for instance perform memory moves when 'moveArea' is invoked.

However, i must admit that i don't have a clear proposal for "redrawing of the exposed regions" with this scheme... and keeping a buffer of everything 'hidden' by other areas is usually not a valid option ...

Further, what about informing the gui service about a mouse event via a signal sent by the mouse driver? The according signal handler would then kick off the mouse handling in the gui service which fetches mouse packets and does what it has to do?

When you say "the gui service fetches mouse packet", are you thinking about "the gui service fetches bytes from port 0x60" or "the gui service get the pre-decoded mouse information from a software fifo" ?

Kicking the GUI service through some signal is of course an interresting thing to do. Letting it get the raw things from the raw hardware wouldn't (imho)

Image May the source be with you.

Mobius handles this by having a thread constantly reading from the mouse device (it is a file). So the mouse thread is blocked until a new data packet arrives from the mouse, at which point it moves the cursor, then goes back to reading.

@Pype: I indeed mean: fetching the first packet of precoded data from a mouse fifo - it can as well be a "file" as Tim does.

ad framebuffer: It's because of the micro kernel design: at the moment I have the gui service draw the screen contents into a buffer and after drawing 's finished inform the video driver about screen data to be fetched.

The video driver copies the data into the frame buffer.

Sure, on a pc with a decent graphics adapter and a decent processor, it works rather well. But it's annoying and complicated design and a hell to debug.

@tim: that's a good Idea: having a dedicated thread listening for mouse movements.

stay safe

... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image

i prefer not talking about 'file' for this ... a 'file' is seek-able. A fifo isn't, and clearly your mouse packets queue is *not* seek-able :P

Image May the source be with you.

but by abstracting it into the *file*-scheme, it would ease many things. f. ex. one can say fcntl(DUPFD,fd-mouse).

In AOS I use a messaging-type subsystem for the input messages, they're delivered in the type of (MESSAGE_INPUT, CTIME, ACTION), so that each program can take their response to a certain action if so desired. The actions are also ordered (you get the time at which they happened along with the info what happened), so you can not screw up the inputs you get like it happens in windows (hey... my password was accidentally redirected to an msn window... that's not cool... happens all the time :().

Programs only get the inputs they should get, and they get all inputs that occur during the time the focus is set to them. The user environment is configurable, and you can of course define environments for a certain user. This results in a number of "events" that can happen, and each event can be coupled by the user program to the "default action", that is, redirection to the GUI service, redirection to the input service, or it can do SomethingCompletelyDifferent(tm), such as interpreting keyboard make/breaks as game input, for controls etc.

I hope this makes the environment more configurable, especially since all input that ends up at the user level has been parsed through the user settings, so you can make a virtual mouse or virtual keyboard from whatever you do have. External applications can also send input to the currently-focussed application, so you can make an onscreen keyboard, and automate tasks using that kind of input.

I'm considering adding logging of input streams, so you can make a "demo" of the programs function using that input stream as actions, possibly together with what you add as comment.

munch munch ... i must have eaten too much OOP these last days ...

what was rolling in /dev/brain is that it makes no sense to say 'everything is a file' if sometimes you can seek a file and sometimes you cannot...

The unix approach says 'fifos, character devices, sockets are files ... they just cannot do everything a 'regular' file can!' while OOP programming would prefer 'fifos, character devices, sockets and files are all X ... but files can do more than what X can ...'

Image May the source be with you.

Pype.Clicker wrote: what was rolling in /dev/brain is that it makes no sense to say 'everything is a file' if sometimes you can seek a file and sometimes you cannot...

Or, put directer, UNIX doesn't work according to "Make it as simple as it can be, but no simpler - Einstein". The dude was right.

The unix approach says 'fifos, character devices, sockets are files ... they just cannot do everything a 'regular' file can!' while OOP programming would prefer 'fifos, character devices, sockets and files are all X ... but files can do more than what X can ...'

And if you model them as such in your c++ environment, as opposed to the current STL template idea (I think it models it the same, not sure), you'll have a more powerful OS.

PS: in some cases, I'd rather get event messages telling me something has happened. Input is one such things, it just makes no sense to have a pipe of inputs where a key being hit is an _event_, not an _input stream_.

Same for listening sockets, you don't block a thread on it actively, you let the app tell you it wants to "open that port for listening", and you then deliver messages to its inbox telling it that "there is a connection request from x.x.x.x:y to z.z.z.z@a, at time b", so you can reply as you should. Of course, it's even better if there's a default way to do popup threads, but my head is still munching the ideas around that. I'm now thinking about a handle_t defer(&function, ...) where the deferred function is executed at SOME time in the future, after which a signal is sent to that handle. If something is listening at the handle, it's awaken at the time of completion, so you can do more than one thing at once, without thread sync problems... Point is, how the **** do I write down that defer function without compiler warnings?

You recommend then, that I introduce an additional interface to fifos/sockets/pipes/mouse-kbd-inputstreams?

Gonna think about this. Just want to have an acceptable way of abstraction for them. To open the mouse device and then read from it seems quite straight to me, but I might be in err.

... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image

beyond infinity wrote: You recommend then, that I introduce an additional interface to fifos/sockets/pipes/mouse-kbd-inputstreams?

I would be tempted to try to simulate the default Unix File, though a Clicker file would more look like a factory of stream (say, you could tell Mydocument.getRStream("chapter1"))

And of course

Image May the source be with you.

Instead of having a reset function, you could make sure the client never gets lost: only ever send fixed-size packets from the server, and only ever allow the client to receive fixed-size packets.