[lkml]   [2007]   [May]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] enhancing the kernel's graphics subsystem
On 5/20/07, Jesse Barnes <> wrote:
> With the interfaces implemented here, a userspace application can create a
> multiseat environment either with a single graphics card with multiple
> outputs or multiple cards. It could do this by creating several frame
> buffer objects and associating them with whatever CRTCs were available,
> and managing input via existing APIs. I don't know of anyone that's done
> this yet though...

This design still requires a global server app since the heads share a
single device.
I am always concerned that the root priv code in the X server is a
potential security hole. I would like to move away from a model where
there is a global controlling app. I don't think we need a global
controlling app at all.

By making one device per head it becomes possible to assign ownership
of the device to the specific user and let them do whatever they want
to it. It's then up to the device driver to sort everything out. fbdev
has already been designed with this in mind and I believe the Matrox
driver implements it. This model easily expands from one to N heads.

Merged-fb modes are handled by including them in the allowable modes
list on both heads. If you own both heads you can set a merged-fb mode
and the other device will just return EBUSY.

How are you reconciling the introduction of a new mode setting API
with the 90 existing fbdev drivers? We clearly don't want two
competing APIs in the kernel. What's the plan for converting all of
the existing drivers?

Jon Smirl
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-05-21 02:51    [W:0.157 / U:5.752 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site