> > 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 > :)
Yep, I'm pulling every day at the moment. If you think the 965GM is good to develop on, I'll have a go at debugging what's going wrong. > > 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 :) Hmm... If you have to use gallium to talk to the hardware, shouldn't fbcon be renamed to glcon? :-) Also, while 2D is dissappearing on desktop, it's very much alive on embedded, for the moment at least. I can't see fbdev going anytime soon if the only replacement is a full-blown programmable 3D driver architecture. Perhaps a new, simple API could be created. On desktop it would be implemented as a new front-end API for gallium and on embedded it would be implemented using a thin user-space wrapper to the kernel module? A bit like what DirectFB started life as (before it started trying to be X). > > 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. Alas I believe the intelfb driver doesn't support the 965GM, at least not in 2.6.24. I think I'll work by logging in over ssh. Doesn't matter then if the screen gets garbled after exiting. Or do I need to run from a vt? Cheers, Tom ------------------------------------------------------------------------- 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
