Writing a new driver for nested Xorg servers based on Xephyr code

Adam Jackson ajax at nwnk.net
Wed Oct 8 05:25:05 PDT 2014


On Mon, 2014-10-06 at 12:32 -0700, Jamey Sharp wrote:
> On Sep 26, 2014 7:52 AM, "Laércio de Sousa"
> <laerciosousa at sme-mogidascruzes.sp.gov.br> wrote:
> > Now I've started playing with xf86-video-nested and Xephyr code,
> trying to merge as much code as possible. It's still in an embrionary
> stage, so I want to ask you some questions:
> >
> > * Is there an official position from X.Org development team about
> deprecating Xephyr in favour of a driver based approach for nesting
> Xorg server? Or at least let both approaches coexist (maybe moving
> common code to a shared library, as I've asked you previously)?
> 
> Asking for an official position isn't especially effective in this
> community, as we don't have anyone designated as a decision-maker. But
> perhaps we can have a conversation about this question at the X.Org
> Developers Conference in Bordeaux this week.
> 
> My personal opinion is that we might as well turn all the current X
> servers into Xorg loadable drivers, but obviously we don't have a
> community-wide consensus on that. ;-)

Eh.  I like the idea I guess, but I don't think the xfree86 DDX is a
good place to realize the idea.  Trying to wedge xwayland into that
model was a little painful, since you basically need to invent whole new
driver classes to convince Xorg to do less work (not eating events from
the tty, etc).  And then you have to start considering how to handle
mixed setups like nested as screen 0 and fbdev as screen 1... it's all
quite hideous.

If xfree86's driver model were cleaned up (epoched, really) to make this
more sensible to reason about, I'd be more enthusiastic.  As it is
turning Xnest into an Xorg-loadable driver solves problems I'm not
having while creating whole new ones.

- ajax



More information about the xorg-devel mailing list