Alternative approach for a nested-xserver based video driver

[Laércio de Sousa]

Thanks guys!

I've just started to work on xf86-video-nested code. I've written an almost
full XCB client (replacing original Xlib one) with some little parts from
Xephyr. It still needs a Xlib Display struct until I can port all XKB
related code to xcb-xkb.

Next step is identifying common parts between Xephyr and nested. Maybe we
can start with hostx.c, which has several features implemented in nested
Xlib/XCB client. The big challenge here is replacing all Kd* stuff in
Xephyr code to something else. We could even write a kdrive-mini.h file
with custom definitions for kdrive struct used in Xephyr, like
KdScreenInfo, so we don't need to rename them in Xephyr code.

My work is avaliable at https://github.com/oiteam/xf86-video-nested. Feel
free to fork it and send me some pull requests.

Att.


2014-06-04 13:56 GMT-03:00 Jamey Sharp <jamey at minilop.net>:

> I'm almost entirely in support of this plan too :-) except I don't think
> it will ever make sense to do things like video-nested or VNC as any
> combination of video-modesetting and libinput.
>
> But for everything else, yes, absolutely, throw that code away. :-)
>
> Jamey
>
> On Wed, Jun 04, 2014 at 12:19:41PM -0400, Jasper St. Pierre wrote:
> > And on the other side, you have people like me who simply want to replace
> > all video drivers with -modesetting, and all input drivers with libinput
> :)
> >
> >
> > On Wed, Jun 4, 2014 at 12:16 PM, Jamey Sharp <jamey at minilop.net> wrote:
> >
> > > On Wed, Jun 04, 2014 at 09:07:22AM -0300, Laércio de Sousa wrote:
> > > > Hello there!
> > > >
> > > > Some time ago I've wrotten asking for current status of
> xf86-video-nested
> > > > development. I believe that, for a more robust single-card multiseat
> > > setup
> > > > with systemd-logind, a "real" Xorg server with some kind of nested
> video
> > > > driver works better than Xephyr, since it still lacks proper input
> > > > hotplugging, for example.
> > > >
> > > > On the other hand, xf86-video-nested have received no relevant
> > > improvements
> > > > for years, while Xephyr graphics support development is quite active.
> > >
> > > Wow, I can't believe that capstone project was almost three years ago
> > > already.
> > >
> > > > So I'm thinking on rewriting xf86-video-nested driver based on latest
> > > > Xephyr code. A more ambicious idea is to identify and move all video
> > > > related code that could be useful for both Xephyr and nested driver
> to a
> > > > shared library, namely "libephyr", and link them against it. We could
> > > even
> > > > rename xf86-video-nested to xf86-video-ephyr to reflect the new
> approach.
> > > >
> > > > I have absolutely no experience in writing video drivers for Xorg,
> but
> > > I'm
> > > > open for learning. Any feedback from you will be welcome.
> > >
> > > In my opinion, this would be great. One of my long-term goals is to
> have
> > > only one X server implementation that anyone cares about, so being able
> > > to replace both Xnest and Xephyr with Xorg+video-ephyr sounds good to
> > > me. (And ideally, Xdmx would die in a fire.)
> > >
> > > If I had my way, you wouldn't need to build a shared library, because
> > > you'd just replace Xephyr. But practicality suggests that your shared
> > > library plan is a better migration strategy.
> > >
> > > I might suggest that you try hacking stuff into video-nested by
> > > copy-paste before you try to figure out what shared library API you
> > > need, though. It's much easier to make progress through incrementally
> > > testable changes.
> > >
> > > I hope this helps. :-)
> > > Jamey
> > >
> > > _______________________________________________
> > > xorg-devel at lists.x.org: X.Org development
> > > Archives: http://lists.x.org/archives/xorg-devel
> > > Info: http://lists.x.org/mailman/listinfo/xorg-devel
> > >
> >
> >
> >
> > --
> >   Jasper
>



-- 
*Laércio de Sousa*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.x.org/archives/xorg-devel/attachments/20140703/328a486c/attachment.html>