On Tue, 18 Mar 2008 17:54:47 +0100 Tom Cooksey <[EMAIL PROTECTED]> wrote: > > > I've had some time to play with the modesetting branch. I am using a laptop > with > an Intel 965GM, is this likely to work? At the moment, when I run > tests/modedemo > I get a hard lock. :-/
Well there is fixes pushed allmost everydays so make sure to use lastest git :) > > I have a few comments/questions from what I've looked at so far: > > 1) The current libdrm looks to be a very thin wrapper around the ioctls. If > this is the > case and all the code is kernel-side, what are the thoughts of implementing a > linuxfb > driver ontop of this? It would be pretty cool to get fbcon rendering using > DRM? Implementing fbcon in userspace have been on the table as a fun things that we might do. > 2) Sortof related to the above... it would be very cool to have a very simple > drawing > API to use on top of the modesetting API. A simple blit & solid fill would > surfice. I've > always found it odd that the internal kernal API for framebuffer devices > includes blit > and solid fill, but that API is never exposed to user-space applications - > even though > it would be _very_ useful. I don't think this will be done. Main reason is that newer hw is hard to program, no 2d anymore so you have to program the whole 3d pipeline stuff and we don't want such code in kernel. So the idea here is to use one userspace driver like gallium3d. Basicly you do a winsys for your use and you can also do a new frontend for gallium other than a GL frontend or wait for new frontend to appear :) > 3) The drmBOCreate() looks fun. Could we use this to store pixmaps? Again, > having > an API to blit a pixmap created with drmBOCreate() to the framebuffer, would > be very > nice. Even nicer if porter-duff composition modes were supported, although a > simple > blit would be a massive leap forward. The idea is that every piece of informations (pixmap, vertex buffer, frame buffer, ...) the GPU might deal with should be allocated in BO. > 4) The API doesn't seem to provide any mechenism for syncing framebuffer > updates > to VBLANK. Does this mean the sync is done automatically, i.e. after > unmapping the > framebuffer, the contents on the screen aren't actually updated until the > next vblank? Kristian is still evaluating which way and how we gona enable syncing with vblank. This will likely happen through a tasklet in the kernel responsible for firing framebuffer update at vblank. > 5) Can we implement double-buffering by creating 2 BOs and switching between > them using drmModeAddFB()? I think interface is their to do double-buffering but maybe not. Lazy to check the code. Anyway we will have somethings at somepoint in the future if not already. > 6) What is the plan for this modesetting work? Is it intended to replace fbdev > or suplement it? From what I've seen, there's nothing stopping you creating a > DRM > driver for very basic framebuffer-only type hardware? In my opinion it should replace fbdev and i think fbdev are depreciated at least i know some people working on it now only do maintenance things. > 7) The modedemo/demo.c seems to be doing stuff with /dev/fb0. From what I can > tell, this is just getting the current mode at startup & restoring it before > exit. Can > I assume this is to stop garbled output after the program exits and can be > safely > #defined out (as I'm using VGA console)? > Lot of the interface is not mature yet so there is few hack to work around things. But in your case you shouldn't define out this as drm modesetting should have take over your vga console (at least this what i do on radeon) so you should be using fbcon. Cheers, Jerome Glisse <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
