Re: [RFC] Does fbdev need a cursor API for userland?

[Jon Smirl <jonsmirl@gmail.com>]

On Mon, 18 Oct 2004 09:20:39 +0800, Antonino A. Daplas
<adaplas@hotpop.com> wrote:
> On Monday 18 October 2004 06:25, Jon Smirl wrote:
> > On Sun, 17 Oct 2004 23:47:15 +0800, Antonino A. Daplas
> >
> > <adaplas@hotpop.com> wrote:
> > > IMO, I believe that the cursor ioctl should just be removed :-)
> >
> > The merged fbdev/DRM needs hardware cursor support in fbdev but it
> 
> A kernel-to-kernel interface to the hardware cursor is easier to implement since
> we always trust kernel data, so that is not much of a problem. The problematic
> area is the generic, non-fbcon specific cursor implementation, and exporting
> the interface to userspace. All are doable of course, and I'm willing to code it
> if people want it.

Merged fbdev/DRM is being built as a platform to run mesa-solo on.
mesa-solo is the standalone OpenGL implementation. X on GL will then
run on top of mesa-solo. Do this will get X out of the device driver
business.

The downside is that Merged fbdev/DRM has to pick up the load that the
2D XAA drivers were carrying and part of that is support for the
hardware cursor. The other major component is mode setting support.

Another large area I am working on is making all heads work on
multihead cards with the merged fbdev/DRM driver. Bringing up multi
head in this environment has exposed some design problems in the
fb_info structures. The structure doesn't sort out things that there
are only one of vs multiple ones.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl