| Submitter | Jeremy Huddleston |
|---|---|
| Date | 2012-03-26 23:13:46 |
| Message ID | <E984C731-7766-45ED-A8A4-52CBDE62DBDF@apple.com> |
| Download | mbox |
| Permalink | /patch/9650/ |
| State | New |
| Headers | show |
Pull-request
git://people.freedesktop.org/~jeremyhu/xserver puntageComments
<#part sign=pgpmime> On Mon, 26 Mar 2012 16:13:46 -0700, Jeremy Huddleston <jeremyhu@apple.com> wrote: > Most functionality of these servers can be provide by Xorg with either > the nested or dummy video driver. I'm all for deleting the code. I would like to have some idea of what you mean by 'most' here -- is there any significant functionality which isn't provided by the xf86-video drivers?
On Mon, 2012-03-26 at 16:13 -0700, Jeremy Huddleston wrote: > These need to die. This removes 30K lines of code from xorg-server. It must be good! > > Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. > > Ok, you may now commence with the flinging of FUD. I use /usr/bin/Xvfb Xvfb :1 -fbdir /var/tmp/ export DISPLAY=:1 sdl-gnash --screenshot 0 --screenshot-file $IMG.tmp -r1 -t1 $SWF kind of a flash ripper . in other day I saw /usr/bin/xvfb-run is in use on building miro-4.0.6-2.fc16 how we test X in a server without displays ? Thanks,
2012/3/26 Sérgio Basto <sergio@serjux.com>: > in other day I saw /usr/bin/xvfb-run is in use on building > miro-4.0.6-2.fc16 > > how we test X in a server without displays ? Use xf86-video-dummy with the Xorg DDX. > I use > /usr/bin/Xvfb > > Xvfb :1 -fbdir /var/tmp/ > export DISPLAY=:1 > sdl-gnash --screenshot 0 --screenshot-file $IMG.tmp -r1 -t1 $SWF > > kind of a flash ripper . xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks like you aren't actually making use of the mmap'd framebuffer in /var/tmp/. So this case should work just fine with xf86-video-dummy today as well. Jamey
On Mon, 2012-03-26 at 16:55 -0700, Jamey Sharp wrote: > 2012/3/26 Sérgio Basto <sergio@serjux.com>: > > in other day I saw /usr/bin/xvfb-run is in use on building > > miro-4.0.6-2.fc16 > > > > how we test X in a server without displays ? > > Use xf86-video-dummy with the Xorg DDX. where is the code ? I need some examples to understand what you are saying ! start a whole X with a xf86-video-dummy instead of Xvfb :1 ? > > I use > > /usr/bin/Xvfb > > > > Xvfb :1 -fbdir /var/tmp/ > > export DISPLAY=:1 > > sdl-gnash --screenshot 0 --screenshot-file $IMG.tmp -r1 -t1 $SWF > > > > kind of a flash ripper . > > xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks > like you aren't actually making use of the mmap'd framebuffer in > /var/tmp/. So this case should work just fine with xf86-video-dummy > today as well. > > Jamey
On Mon, 2012-03-26 at 16:55 -0700, Jamey Sharp wrote: > xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks > like you aren't actually making use of the mmap'd framebuffer in > /var/tmp/. But is an interesting feature , seeing what happen in that framebuffer ... , so if you don't have a real replacement , I do not agree with delete of Xvfb. Others (kdrive, Xnest) never used before. Thanks,
On 03/26/2012 04:55 PM, Jamey Sharp wrote: > 2012/3/26 Sérgio Basto <sergio@serjux.com>: >> in other day I saw /usr/bin/xvfb-run is in use on building >> miro-4.0.6-2.fc16 >> >> how we test X in a server without displays ? > > Use xf86-video-dummy with the Xorg DDX. > >> I use >> /usr/bin/Xvfb >> >> Xvfb :1 -fbdir /var/tmp/ >> export DISPLAY=:1 >> sdl-gnash --screenshot 0 --screenshot-file $IMG.tmp -r1 -t1 $SWF >> >> kind of a flash ripper . > > xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks > like you aren't actually making use of the mmap'd framebuffer in > /var/tmp/. So this case should work just fine with xf86-video-dummy > today as well. I haven't looked into screen scraping much, but I thought it wasn't supported by the dummy video driver. I'm glad to see it is. What does it take to get a screen capture out of the dummy driver? Is it something you would recommend we encapsulate inside of xorg-gtest? Thanks!
On Mon, Mar 26, 2012 at 4:31 PM, Keith Packard <keithp@keithp.com> wrote: > On Mon, 26 Mar 2012 16:13:46 -0700, Jeremy Huddleston <jeremyhu@apple.com> wrote: >> Most functionality of these servers can be provide by Xorg with either >> the nested or dummy video driver. +1 for deleting these obsolete DDXes. I'd suggest deleting Xdmx as well. > I'm all for deleting the code. I would like to have some idea of what > you mean by 'most' here -- is there any significant functionality which > isn't provided by the xf86-video drivers? I don't have a complete list, but here are some things. Timothy Meade thinks there may be some bugs in xf86-video-fbdev compared to Xfbdev, and had other complaints when I tried to remove Xfbdev a year ago: http://lists.x.org/archives/xorg-devel/2011-May/022177.html Xvfb has -fbdir and -shmem options to allocate the framebuffer in a mmap'd file or a shared memory segment, respectively. Surely nobody cares? If somebody does, patches copying the code from Xvfb to xf86-video-dummy should be easy to write. Xnest has options for configuring the created window. Again, I doubt anyone cares, but it's easy functionality to re-introduce in xf86-video-nested if someone wants to. I think Xephyr has support for some extensions that may not be supported when using xf86-video-nested. Perhaps Xv and DRI? Or maybe DRI support was in patches that never got merged, like the Xephyr XCB patches. Xdmx has a complicated GLX proxy to support indirect GL spanning multiple ScreenRecs under Xinerama. It might be nice to find a way to merge that into DIX or the xfree86 DDX. Bonus points if Mesa had a multihead libGL that could delegate direct rendering for each ScreenRec to an appropriate libGL. :-) Generally, I think Xdmx may have support for some extensions that Xorg doesn't support when Xinerama is turned on, and it'd be nice to copy that over. It might be nice to have backwards-compatibility shell scripts for the replaced programs that convert their command-line arguments into a suitable xorg.conf and then run the real server. That's everything I can think of. I'm not convinced any of those are worth waiting for before deleting these DDXes. Jamey
On Mon, Mar 26, 2012 at 5:09 PM, Chase Douglas <chase.douglas@canonical.com> wrote: > On 03/26/2012 04:55 PM, Jamey Sharp wrote: >> xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks >> like you aren't actually making use of the mmap'd framebuffer in >> /var/tmp/. So this case should work just fine with xf86-video-dummy >> today as well. > > I haven't looked into screen scraping much, but I thought it wasn't > supported by the dummy video driver. I'm glad to see it is. > > What does it take to get a screen capture out of the dummy driver? Is it > something you would recommend we encapsulate inside of xorg-gtest? Sure, GetImage on the root window works just like it does on any other video driver. Jeremy, Josh, and I sponsored a recently-completed capstone project where the students produced quite a bit of code relying on that: http://cgit.freedesktop.org/xorg/lib/libxcwm/ I haven't paid too much attention to xorg-gtest; I assume it's a framework for building X server test suites? I'd certainly recommend using xf86-video-dummy if you're kicking off an X server during any automated test procedure. Sometimes people might appreciate a configuration option to use xf86-video-nested instead, so they can see the test output. I'm not sure there's anything else you'd need to encapsulate in xorg-gtest that's specific to the dummy driver though. Jamey
On 03/26/12 04:13 PM, Jeremy Huddleston wrote: > These need to die. This removes 30K lines of code from xorg-server. It must be good! > > Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. The giant blocker from my point of view is that by just deleting them, you've made it impossible for non-root users to run them, since Xorg only reads config files from system directories when run as a root user. At the very minimum we should ship a couple simple configs such as (guessing at contents here, someone would need to test and refine): /usr/lib/X11/Xorg-vfb.conf: ------------------------------ Section "Device" Identifier "vfb0" Driver "dummy" EndSection Section "ServerFlags" Option "AutoAddDevices" "false" EndSection ------------------------------ /usr/lib/X11/Xorg-nested.conf: ------------------------------ Section "Device" Identifier "Screen0" Driver "nested" EndSection Section "ServerFlags" Option "AutoAddDevices" "false" EndSection Section "InputDevice" Identifier "Mouse0" Driver "nested" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "nested" EndSection ------------------------------ Even better would be to ship Xephyr, Xvfb, Xnest as simple shell scripts that did basically "Xorg -config Xorg-vfb.conf $*" (possibly with some argument manipulation for other arguments those supported).
On 03/26/2012 05:50 PM, Jamey Sharp wrote: > On Mon, Mar 26, 2012 at 5:09 PM, Chase Douglas > <chase.douglas@canonical.com> wrote: >> On 03/26/2012 04:55 PM, Jamey Sharp wrote: >>> xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks >>> like you aren't actually making use of the mmap'd framebuffer in >>> /var/tmp/. So this case should work just fine with xf86-video-dummy >>> today as well. >> >> I haven't looked into screen scraping much, but I thought it wasn't >> supported by the dummy video driver. I'm glad to see it is. >> >> What does it take to get a screen capture out of the dummy driver? Is it >> something you would recommend we encapsulate inside of xorg-gtest? > > Sure, GetImage on the root window works just like it does on any other > video driver. Jeremy, Josh, and I sponsored a recently-completed > capstone project where the students produced quite a bit of code > relying on that: > > http://cgit.freedesktop.org/xorg/lib/libxcwm/ Thanks for the tip, we'll look into it. > I haven't paid too much attention to xorg-gtest; I assume it's a > framework for building X server test suites? I'd certainly recommend > using xf86-video-dummy if you're kicking off an X server during any > automated test procedure. Sometimes people might appreciate a > configuration option to use xf86-video-nested instead, so they can see > the test output. I'm not sure there's anything else you'd need to > encapsulate in xorg-gtest that's specific to the dummy driver though. Yeah, it kicks off a background X server using the dummy video driver by default. You can use the --no-dummy-server option when running tests to run them on the current $DISPLAY server, and you can specify your own xorg.conf with nested if needed. If it's really as simple as using XGetImage, then we probably don't need to abstract it any inside xorg-gtest. -- Chase
On 2012-03-26 18:13, Jeremy Huddleston wrote: > These need to die. This removes 30K lines of code from xorg-server. > It must be good! > > Most functionality of these servers can be provide by Xorg with either > the nested or dummy video driver. If someone really misses > functionality, we should fix that deficiency in hw/xfree86, > xf86-video-dummy, or xf86-video-nested. Also, there's nothing > stopping anyone from using older server versions if they still need > these DDXs. > > Ok, you may now commence with the flinging of FUD. As a non-Xorg DDX maintainer, several quick questions that jump to mind: 1. Will Xorg even work on Cygwin/MinGW? (I would ask the same of OS X, but as the Xquartz maintainer I suppose you know what you are doing.) Even if it does, I see already it would take some serious patching to build due to the module-based architecture, which I would be willing to work on. 2. XWin must still provide the /usr/bin/X symlink on Cygwin/MinGW. 3. We would definitely need the wrapper scripts mentioned by Alan to replace the removed DDXs. Yaakov Cygwin/X
On 03/26/12 06:01 PM, Alan Coopersmith wrote: > On 03/26/12 04:13 PM, Jeremy Huddleston wrote: >> These need to die. This removes 30K lines of code from xorg-server. It must be good! >> >> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. > > The giant blocker from my point of view is that by just deleting them, you've > made it impossible for non-root users to run them, since Xorg only reads config > files from system directories when run as a root user. Oh, and there's probably at least two other alternative solutions to this too: a) install a non-setuid-root copy of Xorg and have Xnest/Xephyr/Xvfb run that b) have the config file parser recognize 'safe' vs. 'unsafe' options, and only accept config files from non-root users that contain purely safe options (e.g. no ModulePath that lets them specify their own modules to load and run with root privs). Of course, besides (a) being much less work and much less risky if you make a mistake, it's also preparing for the dream of a Xorg server that can run without root privs someday, while the huge amount of work for (b) would end up being wasted if that day ever comes to pass.
On Mar 26, 2012, at 6:01 PM, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > On 03/26/12 04:13 PM, Jeremy Huddleston wrote: >> These need to die. This removes 30K lines of code from xorg-server. It must be good! >> >> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. > > The giant blocker from my point of view is that by just deleting them, you've > made it impossible for non-root users to run them, since Xorg only reads config > files from system directories when run as a root user. Yes, and this is certainly something we should address this cycle. There's no reason that Xorg needs to be suid root when using drivers like dummy, nested, vnc, ... > At the very minimum we should ship a couple simple configs such as (guessing at > contents here, someone would need to test and refine): > > /usr/lib/X11/Xorg-vfb.conf: > ------------------------------ > Section "Device" > Identifier "vfb0" > Driver "dummy" > EndSection > > Section "ServerFlags" > Option "AutoAddDevices" "false" > EndSection > ------------------------------ > > > /usr/lib/X11/Xorg-nested.conf: > ------------------------------ > Section "Device" > Identifier "Screen0" > Driver "nested" > EndSection > > Section "ServerFlags" > Option "AutoAddDevices" "false" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "nested" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "nested" > EndSection That's pretty much what I'm shipping in the current XQuartz betas for this purpose.
On Mar 26, 2012, at 7:37 PM, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > On 03/26/12 06:01 PM, Alan Coopersmith wrote: >> On 03/26/12 04:13 PM, Jeremy Huddleston wrote: >>> These need to die. This removes 30K lines of code from xorg-server. It must be good! >>> >>> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. >> >> The giant blocker from my point of view is that by just deleting them, you've >> made it impossible for non-root users to run them, since Xorg only reads config >> files from system directories when run as a root user. > > Oh, and there's probably at least two other alternative solutions to this too: > > a) install a non-setuid-root copy of Xorg and have Xnest/Xephyr/Xvfb run that This is the option I prefer, although I'd rather have ${bindir}/Xorg and ${bindir}/Xorg.suid to make it obvious which is which (and which is "the future").
On 03/26/12 07:50 PM, Jeremy Huddleston wrote: > On Mar 26, 2012, at 7:37 PM, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: >> a) install a non-setuid-root copy of Xorg and have Xnest/Xephyr/Xvfb run that > > This is the option I prefer, although I'd rather have ${bindir}/Xorg and ${bindir}/Xorg.suid to make it obvious which is which (and which is "the future"). And I'd rather not break the vast majority of existing users & configurations, which suggests leaving Xorg suid and making the new one (Xother?) non-suid, unless someone can figure out a clever way to make it work with a wrapper. Perhaps ${libexecdir}/Xorg.suid & ${libexecdir}/Xorg and have /usr/bin/Xorg be a non-suid wrapper that execs ${libexecdir}/Xorg.suid unless -config has a path that's not allowed in the suid form, in which case it runs the non-suid one instead?
On Mon, Mar 26, 2012 at 6:01 PM, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > On 03/26/12 04:13 PM, Jeremy Huddleston wrote: >> These need to die. This removes 30K lines of code from xorg-server. It must be good! >> >> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. > > The giant blocker from my point of view is that by just deleting them, you've > made it impossible for non-root users to run them, since Xorg only reads config > files from system directories when run as a root user. I'm glad to hear you have no objections: this is all fixed in 1.12. See ead968a4300c0adeff89b9886e888b6d284c75cc Jamey
On 03/26/12 08:21 PM, Jamey Sharp wrote: > On Mon, Mar 26, 2012 at 6:01 PM, Alan Coopersmith > <alan.coopersmith@oracle.com> wrote: >> On 03/26/12 04:13 PM, Jeremy Huddleston wrote: >>> These need to die. This removes 30K lines of code from xorg-server. It must be good! >>> >>> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. >> >> The giant blocker from my point of view is that by just deleting them, you've >> made it impossible for non-root users to run them, since Xorg only reads config >> files from system directories when run as a root user. > > I'm glad to hear you have no objections: this is all fixed in 1.12. See > > ead968a4300c0adeff89b9886e888b6d284c75cc Nice try, but did you read that commit? if (!strcmp(argv[i], "-config") || !strcmp(argv[i], "-xf86config")) { CHECK_FOR_REQUIRED_ARGUMENT(); - if (getuid() != 0 && !xf86PathIsSafe(argv[i + 1])) { + if (xf86PrivsElevated() && !xf86PathIsSafe(argv[i + 1])) { FatalError("\nInvalid argument for %s\n" - "\tFor non-root users, the file specified with %s must be\n" + "\tWith elevated privileges, the file specified with %s must be\n" It will still FatalError if you attempt to pass a -config path when the server is installed setuid, as it currently must be to support actual hardware configurations.
On Mon, Mar 26, 2012 at 8:30 PM, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > On 03/26/12 08:21 PM, Jamey Sharp wrote: >> On Mon, Mar 26, 2012 at 6:01 PM, Alan Coopersmith >> <alan.coopersmith@oracle.com> wrote: >>> The giant blocker from my point of view is that by just deleting them, you've >>> made it impossible for non-root users to run them, since Xorg only reads config >>> files from system directories when run as a root user. >> >> I'm glad to hear you have no objections: this is all fixed in 1.12. See >> >> ead968a4300c0adeff89b9886e888b6d284c75cc > > Nice try, but did you read that commit? > > It will still FatalError if you attempt to pass a -config path when the server > is installed setuid, as it currently must be to support actual hardware > configurations. Oh. Right. I forgot the details after reviewing the patch, apparently. I certainly did read the commit at some point; it says so right on it. :-) Maybe I have it right this time: On Debian, there's no problem, because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not installed suid. Solaris and other Unixes could take the same approach, right? Jamey
On Mon, Mar 26, 2012 at 6:31 PM, Yaakov (Cygwin/X) <yselkowitz@users.sourceforge.net> wrote: > As a non-Xorg DDX maintainer, several quick questions that jump to mind: > > 1. Will Xorg even work on Cygwin/MinGW? (I would ask the same of OS X, but > as the Xquartz maintainer I suppose you know what you are doing.) Even if it > does, I see already it would take some serious patching to build due to the > module-based architecture, which I would be willing to work on. Ah, that's a good point. Jeremy took care of the issues with running Xorg on OS X during the 1.12 cycle, but that needs to happen for Windows too. I'm hopeful that at least some of the work he did will make that job easier. > 2. XWin must still provide the /usr/bin/X symlink on Cygwin/MinGW. Seems like a packaging issue, not an upstream issue, so I don't think that'll be a problem? However, our capstone project that just finished was a start toward replacing the XQuartz DDX with a stock Xorg server and a special client, and I'm hoping that XWin can go the same direction. The special client acts something like a compositing window manager. It's pretty alpha right now, but proves the concept nicely on OS X. It was designed to have a portable core library shared by several applications, one for each native window system (say, OS X, Windows, and Wayland). Now would be a great time to start generalizing to other window systems. http://cgit.freedesktop.org/xorg/lib/libxcwm/ > 3. We would definitely need the wrapper scripts mentioned by Alan to replace > the removed DDXs. Probably worth having those on any platform, really. Jamey
On 03/26/12 09:07 PM, Jamey Sharp wrote: > Maybe I have it right this time: On Debian, there's no problem, > because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not > installed suid. Solaris and other Unixes could take the same approach, > right? While I've heard about this before, I've not seen the sources for this wrapper (can someone provide a pointer? all I'm finding in google is man pages & bug reports that reference it) However, if the suid wrapper allows non-root users to specify arbitrary files to -config, then it's a dangerous security hole we can't allow (and since the Debian people aren't stupid, I assume it does not). If it doesn't allow -config through, then I don't see how it would help here.
On Mon, Mar 26, 2012 at 10:06:30PM -0700, Alan Coopersmith wrote: > On 03/26/12 09:07 PM, Jamey Sharp wrote: > > Maybe I have it right this time: On Debian, there's no problem, > > because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not > > installed suid. Solaris and other Unixes could take the same approach, > > right? > > While I've heard about this before, I've not seen the sources for this wrapper > (can someone provide a pointer? all I'm finding in google is man pages & bug > reports that reference it) > > However, if the suid wrapper allows non-root users to specify arbitrary files > to -config, then it's a dangerous security hole we can't allow (and since the > Debian people aren't stupid, I assume it does not). If it doesn't allow > -config through, then I don't see how it would help here. Please, not a wrapper again. The wrapper doesn't bring much in terms of security since the controlled Xorg is still run with elevated privileges when needed. Revoking privileges when not needed can be done inside Xorg itself (see the privilege separation changes in the obsd branch of ~herrb/xserver for an example). And not introducing new bugs in the additional code inside the X server is not really more difficult than not creating bugs in the wrapper.
On 2012-03-26 20:31, Yaakov (Cygwin/X) wrote: > 1. Will Xorg even work on Cygwin/MinGW? Well, it *seems* I got Xorg (1.12 branch) with xf86-video-dummy (0.3.5) working, but while xf86-video-nested (git master) will start, clients are unable to connect. I used Alan's conf files and added my own in xorg.conf.d: Section "Module" Load "fb" Load "shadow" Disable "kbd" Disable "mouse" EndSection This is due to video-dummy requiring libfb, video-nested requiring both libfb and libshadow, and libshadow itself requiring libfb. > Even if it does, I see already it would take some serious patching to > build due to the module-based architecture, which I would be willing to > work on. The attached draft patch is how I built Xorg 1.12 on Cygwin. Comments? Yaakov Cygwin/X
On Mon, 2012-03-26 at 22:06 -0700, Alan Coopersmith wrote: > On 03/26/12 09:07 PM, Jamey Sharp wrote: > > Maybe I have it right this time: On Debian, there's no problem, > > because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not > > installed suid. Solaris and other Unixes could take the same approach, > > right? > > While I've heard about this before, I've not seen the sources for this wrapper > (can someone provide a pointer? all I'm finding in google is man pages & bug > reports that reference it) http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xorg.git;a=history;f=debian/local/xserver-wrapper.c
Twas brillig at 22:06:30 26.03.2012 UTC-07 when alan.coopersmith@oracle.com did gyre and gimble: AC> While I've heard about this before, I've not seen the sources for this wrapper AC> (can someone provide a pointer? all I'm finding in google is man pages & bug AC> reports that reference it) http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xorg.git;a=blob;f=debian/local/xserver-wrapper.c;h=d4a6ab8de82e4a7759994e513f20412c8d3e3cd7;hb=HEAD --
On 03/27/2012 06:59 AM, Sérgio Basto wrote: > On Mon, 2012-03-26 at 16:55 -0700, Jamey Sharp wrote: >> 2012/3/26 Sérgio Basto <sergio@serjux.com>: >>> in other day I saw /usr/bin/xvfb-run is in use on building >>> miro-4.0.6-2.fc16 >>> >>> how we test X in a server without displays ? >> >> Use xf86-video-dummy with the Xorg DDX. > > where is the code ? > I need some examples to understand what you are saying ! > > start a whole X with a xf86-video-dummy instead of Xvfb :1 ? https://xpra.org/Xdummy.html#usage Antoine (+1 for removing Xvfb) >>> I use >>> /usr/bin/Xvfb >>> >>> Xvfb :1 -fbdir /var/tmp/ >>> export DISPLAY=:1 >>> sdl-gnash --screenshot 0 --screenshot-file $IMG.tmp -r1 -t1 $SWF >>> >>> kind of a flash ripper . >> >> xf86-video-dummy doesn't have an equivalent to -fbdir, but it looks >> like you aren't actually making use of the mmap'd framebuffer in >> /var/tmp/. So this case should work just fine with xf86-video-dummy >> today as well. >> >> Jamey >
(snip) > At the very minimum we should ship a couple simple configs such as (guessing at > contents here, someone would need to test and refine): (snip) Here is the one I use often (mainly because dummy does not have proper randr support yet - I have offered to help resolve this..): https://xpra.org/xorg.conf Shipping some useful default configs would not be a bad idea IMO. As for Xorg vs suid, I suspect the distros will want to have control over the changeover process, something along the lines of: Xorg -> Xorg.suid Xorg.suid Xorg.nosuid Then, hopefully one day: Xorg -> Xorg.nosuid (or just remove Xorg.suid at that point) > Even better would be to ship Xephyr, Xvfb, Xnest as simple shell scripts that > did basically "Xorg -config Xorg-vfb.conf $*" (possibly with some argument > manipulation for other arguments those supported). +1 for shell scripts that try to do the-right-thing(tm), but from my experience with xpra there are some tricky arguments to handle, ie: Xvfb -screen 0 3840x2560x24+32 :10 I don't see how that can be handled with dummy at present... Antoine
On 3/26/12, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > On 03/26/12 09:07 PM, Jamey Sharp wrote: >> Maybe I have it right this time: On Debian, there's no problem, >> because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not >> installed suid. Solaris and other Unixes could take the same approach, >> right? > > However, if the suid wrapper allows non-root users to specify arbitrary files > to -config, then it's a dangerous security hole we can't allow (and since the > Debian people aren't stupid, I assume it does not). If it doesn't allow > -config through, then I don't see how it would help here. The key is to have a *non*-suid copy of the server available for those who don't need root privs for their configuration. In that mode all options can be processed without the server performing security checks, and if you try to subvert system security the OS will stop you. Systems that still need to allow non-root users to run the server with root privileges (hopefully a dwindling set over time) can either ship a suid wrapper, or ship a second copy of the server that has the suid bit set, whichever makes more sense to the packagers. Jamey
> Date: Tue, 27 Mar 2012 06:03:03 -0700 > From: Jamey Sharp <jamey@minilop.net> > > On 3/26/12, Alan Coopersmith <alan.coopersmith@oracle.com> wrote: > > On 03/26/12 09:07 PM, Jamey Sharp wrote: > >> Maybe I have it right this time: On Debian, there's no problem, > >> because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not > >> installed suid. Solaris and other Unixes could take the same approach, > >> right? > > > > However, if the suid wrapper allows non-root users to specify arbitrary files > > to -config, then it's a dangerous security hole we can't allow (and since the > > Debian people aren't stupid, I assume it does not). If it doesn't allow > > -config through, then I don't see how it would help here. > > The key is to have a *non*-suid copy of the server available for those > who don't need root privs for their configuration. In that mode all > options can be processed without the server performing security > checks, and if you try to subvert system security the OS will stop > you. This is based on the (false) assumption that a suid Xorg is making things less secure. It is perhaps somewhat non-intuitive, but a suid-root binary can use its powers to drop priviliges and become less priviliged than a normal user. So a *non*-suid Xorg should not be a goal in itself.
On 3/27/12, Mark Kettenis <mark.kettenis@xs4all.nl> wrote: >> Date: Tue, 27 Mar 2012 06:03:03 -0700 >> From: Jamey Sharp <jamey@minilop.net> >> >> The key is to have a *non*-suid copy of the server available for those >> who don't need root privs for their configuration. In that mode all >> options can be processed without the server performing security >> checks, and if you try to subvert system security the OS will stop >> you. > > This is based on the (false) assumption that a suid Xorg is making > things less secure. It is perhaps somewhat non-intuitive, but a > suid-root binary can use its powers to drop priviliges and become less > priviliged than a normal user. So a *non*-suid Xorg should not be a > goal in itself. Um... I can't say I'm convinced. 1) Why would you want to engineer the complexity of dropping privs, with plenty of opportunities to get it wrong in ways that lead to root holes? And since every OS has different rules about process permissions, even getting it right on one kernel tells you nothing about whether it's right anywhere else. 2) You aren't offering any advantage to an administrator--if a user's X server is prohibited from doing some things the user is permitted to do, you haven't stopped the user from doing them. So you must be trying to support users who don't trust their X server and want to sandbox it, right? But if they don't trust the X server, they certainly shouldn't rely on it to sandbox itself, especially if it has to have root permissions to do so. By contrast, I think setting the server suid directly to an unprivileged user would be fine, because it doesn't involve any security-sensitive code in the server. Or using a dedicated program that sets up restricted privileges, chroot, unshare, whatever sandboxing you want, and then execs a plain copy of the X server, because the code you have to audit then is small. But no, I'm pretty sure keeping the X server away from root privs is always the right thing, and we're just in a transition period where it isn't always feasible yet. Discussion of privilege is straying a bit far from the original topic, but, well: http://xkcd.com/386/ Jamey
On 03/27/12 12:08 AM, Michel Dänzer wrote: > On Mon, 2012-03-26 at 22:06 -0700, Alan Coopersmith wrote: >> On 03/26/12 09:07 PM, Jamey Sharp wrote: >>> Maybe I have it right this time: On Debian, there's no problem, >>> because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not >>> installed suid. Solaris and other Unixes could take the same approach, >>> right? >> >> While I've heard about this before, I've not seen the sources for this wrapper >> (can someone provide a pointer? all I'm finding in google is man pages & bug >> reports that reference it) > > http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xorg.git;a=history;f=debian/local/xserver-wrapper.c So yes, I see it does try to run Xorg without privileges when any -config option is passed, not just those in unsafe directories, which means that systems using this wrapper can probably get by already. I couldn't use this wrapper as is on Solaris though, since we use the existing support for system/admin provided config files being available to non-root users in a Xorg running as root, such as Xorg -config xorg.conf.vesa to load a fallback vesa configuration. It also wouldn't help the people who were unfortunately using Xephyr with direct input device access to fake up a multiseat mode on a single physical server, though that should probably be replaced by use of nested Xinput devices, not trying to hack up Xorg to use nested video driver with evdev input drivers.
On Mon, 2012-03-26 at 18:01 -0700, Alan Coopersmith wrote: > On 03/26/12 04:13 PM, Jeremy Huddleston wrote: > > These need to die. This removes 30K lines of code from xorg-server. It must be good! > > > > Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. > > The giant blocker from my point of view is that by just deleting them, you've > made it impossible for non-root users to run them, since Xorg only reads config > files from system directories when run as a root user. > > At the very minimum we should ship a couple simple configs such as (guessing at > contents here, someone would need to test and refine): > > /usr/lib/X11/Xorg-vfb.conf: > ------------------------------ > Section "Device" > Identifier "vfb0" > Driver "dummy" > EndSection > > Section "ServerFlags" > Option "AutoAddDevices" "false" > EndSection > ------------------------------ > > > /usr/lib/X11/Xorg-nested.conf: > ------------------------------ > Section "Device" > Identifier "Screen0" > Driver "nested" > EndSection > > Section "ServerFlags" > Option "AutoAddDevices" "false" > EndSection > > Section "InputDevice" > Identifier "Mouse0" > Driver "nested" > EndSection > > Section "InputDevice" > Identifier "Keyboard0" > Driver "nested" > EndSection > ------------------------------ > > Even better would be to ship Xephyr, Xvfb, Xnest as simple shell scripts that > did basically "Xorg -config Xorg-vfb.conf $*" (possibly with some argument > manipulation for other arguments those supported). Thanks for examples, I though a good job , is replace /usr/bin/Xvfb /usr/bin/xvfb-run transparently . Other subject is vnc any replacement for x11vnc and x2vnc, I am worried about applications which use code of X11 like this two: x11vnc-0.9.13-1.fc16.x86_64 rpm -qi x2vnc-1.7.2-12.fc15.x86_64 Name : x2vnc License : GPLv2+ URL : http://fredrik.hubbe.net/x2vnc.html Summary : Dual screen hack for VNC Description : This program will let you use two screens on two different computers as if they were connected to the same computer even if one computer runs Windows. Thanks,
On Mar 27, 2012, at 12:08 AM, Michel Dänzer <michel@daenzer.net> wrote: > On Mon, 2012-03-26 at 22:06 -0700, Alan Coopersmith wrote: >> On 03/26/12 09:07 PM, Jamey Sharp wrote: >>> Maybe I have it right this time: On Debian, there's no problem, >>> because /usr/bin/X is a trivial suid wrapper and /usr/bin/Xorg is not >>> installed suid. Solaris and other Unixes could take the same approach, >>> right? >> >> While I've heard about this before, I've not seen the sources for this wrapper >> (can someone provide a pointer? all I'm finding in google is man pages & bug >> reports that reference it) > > http://anonscm.debian.org/gitweb/?p=pkg-xorg/debian/xorg.git;a=history;f=debian/local/xserver-wrapper.c As a warning, this is GPL-2: 88 * This is free software; you may redistribute it and/or modify 89 * it under the terms of the GNU General Public License as 90 * published by the Free Software Foundation; either version 2, 91 * or (at your option) any later version. I stopped reading after that point, given that we are likely to do something similar, I didn't want to contaminate myself with potential GPL influence. Anyone who might actually write the code for our version of this wrapper should probably avoid reading the source. --Jeremy
2012/3/27 Sérgio Basto <sergio@serjux.com>: > Other subject is vnc any replacement for x11vnc and x2vnc, I am worried > about applications which use code of X11 like this two: > > x11vnc-0.9.13-1.fc16.x86_64 x11vnc is fine: it's just an X client. It works with any Xorg driver. I've used it with xf86-video-dummy before to test X server changes, but that's not usually a useful configuration otherwise. > rpm -qi x2vnc-1.7.2-12.fc15.x86_64 I don't know anything about x2vnc, but my impression is that it is just an X client as well, so it should be fine too. You're probably thinking of the old X VNC servers that hacked up the server source tree. I believe those have been abandoned, but certainly this proposed change won't hurt them any more than they already have been. Jamey
On 03/27/12 10:46 AM, Jamey Sharp wrote: > You're probably thinking of the old X VNC servers that hacked up the > server source tree. I believe those have been abandoned, but certainly > this proposed change won't hurt them any more than they already have > been. TigerVNC is alive and well, shipping both Xvnc standalone server and a vnc.so loadable module for Xorg, neither of which should be broken by this change. It may be possible to eventually replace Xvnc with a Xorg server that loads the vnc module with the dummy video driver and some sort of appropriate input driver (I don't think void will cut it, nor running without input) - but given the GPL license on that code, I'm happiest keeping Xvnc as a completely separate binary.
On Tue, 2012-03-27 at 10:46 -0700, Jamey Sharp wrote: > 2012/3/27 Sérgio Basto <sergio@serjux.com>: > > Other subject is vnc any replacement for x11vnc and x2vnc, I am worried > > about applications which use code of X11 like this two: > > > > x11vnc-0.9.13-1.fc16.x86_64 > > x11vnc is fine: it's just an X client. It works with any Xorg driver. > I've used it with xf86-video-dummy before to test X server changes, > but that's not usually a useful configuration otherwise. > > > rpm -qi x2vnc-1.7.2-12.fc15.x86_64 > > I don't know anything about x2vnc, but my impression is that it is > just an X client as well, so it should be fine too. > > You're probably thinking of the old X VNC servers that hacked up the > server source tree. I believe those have been abandoned, but certainly > this proposed change won't hurt them any more than they already have > been. OK BTW: Have we solution in house , of synergy, X to X ? I put x11vnc on remote X and with x2vnc , I control remote and local X with same mouse and keyboard, also works well copy and paste· Thanks,
On Tue, 2012-03-27 at 10:53 -0700, Alan Coopersmith wrote: > On 03/27/12 10:46 AM, Jamey Sharp wrote: > > You're probably thinking of the old X VNC servers that hacked up the > > server source tree. I believe those have been abandoned, but certainly > > this proposed change won't hurt them any more than they already have > > been. > > TigerVNC is alive and well, shipping both Xvnc standalone server and > a vnc.so loadable module for Xorg, neither of which should be broken > by this change. It may be possible to eventually replace Xvnc with a > Xorg server that loads the vnc module with the dummy video driver and > some sort of appropriate input driver (I don't think void will cut it, > nor running without input) - but given the GPL license on that code, > I'm happiest keeping Xvnc as a completely separate binary. X11vnc is different of TigerVNC URL : http://www.karlrunge.com/x11vnc/ Summary : VNC server for the current X11 session
On 03/28/2012 01:36 AM, Sérgio Basto wrote: > On Tue, 2012-03-27 at 10:53 -0700, Alan Coopersmith wrote: >> On 03/27/12 10:46 AM, Jamey Sharp wrote: >>> You're probably thinking of the old X VNC servers that hacked up the >>> server source tree. I believe those have been abandoned, but certainly >>> this proposed change won't hurt them any more than they already have >>> been. >> >> TigerVNC is alive and well, shipping both Xvnc standalone server and >> a vnc.so loadable module for Xorg, neither of which should be broken >> by this change. It may be possible to eventually replace Xvnc with a >> Xorg server that loads the vnc module with the dummy video driver and >> some sort of appropriate input driver (I don't think void will cut it, >> nor running without input) - but given the GPL license on that code, >> I'm happiest keeping Xvnc as a completely separate binary. > > X11vnc is different of TigerVNC > URL : http://www.karlrunge.com/x11vnc/ > Summary : VNC server for the current X11 session TigerVNC includes x0vncserver which does the same thing.
On Mon, Mar 26, 2012 at 17:37:37 -0700, Jamey Sharp wrote: > On Mon, Mar 26, 2012 at 4:31 PM, Keith Packard <keithp@keithp.com> wrote: > > On Mon, 26 Mar 2012 16:13:46 -0700, Jeremy Huddleston <jeremyhu@apple.com> wrote: > >> Most functionality of these servers can be provide by Xorg with either > >> the nested or dummy video driver. > > +1 for deleting these obsolete DDXes. I'd suggest deleting Xdmx as well. > > > I'm all for deleting the code. I would like to have some idea of what > > you mean by 'most' here -- is there any significant functionality which > > isn't provided by the xf86-video drivers? > > I don't have a complete list, but here are some things. > > Timothy Meade thinks there may be some bugs in xf86-video-fbdev > compared to Xfbdev, and had other complaints when I tried to remove > Xfbdev a year ago: > http://lists.x.org/archives/xorg-devel/2011-May/022177.html > > Xvfb has -fbdir and -shmem options to allocate the framebuffer in a > mmap'd file or a shared memory segment, respectively. Surely nobody > cares? If somebody does, patches copying the code from Xvfb to > xf86-video-dummy should be easy to write. > > Xnest has options for configuring the created window. Again, I doubt > anyone cares, but it's easy functionality to re-introduce in > xf86-video-nested if someone wants to. > > I think Xephyr has support for some extensions that may not be > supported when using xf86-video-nested. Perhaps Xv and DRI? Or maybe > DRI support was in patches that never got merged, like the Xephyr XCB > patches. > Xephyr indeed supports Xv and DRI1. > Xdmx has a complicated GLX proxy to support indirect GL spanning > multiple ScreenRecs under Xinerama. It might be nice to find a way to > merge that into DIX or the xfree86 DDX. Bonus points if Mesa had a > multihead libGL that could delegate direct rendering for each > ScreenRec to an appropriate libGL. :-) > Xdmx's glxproxy has been broken for years. > Generally, I think Xdmx may have support for some extensions that Xorg > doesn't support when Xinerama is turned on, and it'd be nice to copy > that over. > > It might be nice to have backwards-compatibility shell scripts for the > replaced programs that convert their command-line arguments into a > suitable xorg.conf and then run the real server. > I think that should be a requirement before deleting the code, there's quite a few people and scripts using at least Xvfb out there. If indeed the dummy and nested drivers provide the functionality of those other DDXes then that shouldn't even be hard. Cheers, Julien
On 03/27/12 11:36 AM, Sérgio Basto wrote: > On Tue, 2012-03-27 at 10:53 -0700, Alan Coopersmith wrote: >> On 03/27/12 10:46 AM, Jamey Sharp wrote: >>> You're probably thinking of the old X VNC servers that hacked up the >>> server source tree. I believe those have been abandoned, but certainly >>> this proposed change won't hurt them any more than they already have >>> been. >> >> TigerVNC is alive and well, shipping both Xvnc standalone server and >> a vnc.so loadable module for Xorg, neither of which should be broken >> by this change. It may be possible to eventually replace Xvnc with a >> Xorg server that loads the vnc module with the dummy video driver and >> some sort of appropriate input driver (I don't think void will cut it, >> nor running without input) - but given the GPL license on that code, >> I'm happiest keeping Xvnc as a completely separate binary. > > X11vnc is different of TigerVNC > URL : http://www.karlrunge.com/x11vnc/ > Summary : VNC server for the current X11 session Understood, and as previously noted, completely unaffected by this change.
On 2012-03-26 20:01, Alan Coopersmith wrote: > At the very minimum we should ship a couple simple configs such as (guessing at > contents here, someone would need to test and refine): OK, it looks like I have both of these working on Cygwin now. I do remind everyone that video-nested doesn't have a tarball release yet. > Even better would be to ship Xephyr, Xvfb, Xnest as simple shell scripts that > did basically "Xorg -config Xorg-vfb.conf $*" (possibly with some argument > manipulation for other arguments those supported). (Don't forget Xfake.) While I think we do need scripts to replace at least Xvfb (which is used in building a few packages), what about command-line option compatibility? How do you handle "Xvfb -screen 0 640x480x24 :1" or "Xnest -geometry 640x480+100+100 :2" and the like? Yaakov Cygwin/X
On Mon, Mar 26, 2012 at 05:37:37PM -0700, Jamey Sharp wrote: > Xvfb has -fbdir and -shmem options to allocate the framebuffer in a > mmap'd file or a shared memory segment, respectively. Surely nobody > cares? If somebody does, patches copying the code from Xvfb to > xf86-video-dummy should be easy to write. Actually, I cobbled some code together in the last few months that is making use of Xvfb -fbdir, this was to run a Window'ed xserver on OSX. I wanted to avoid the double translation inherent in using vnc, and didn't want to have 2 Xservers running (which using Xnest / Xephyr would have involved). .pdf
AFAIK (which is not very far) Kdrive is still the easiest way to
quickly cobble together a minimalist server for some wacky hardware or
software environment, no? I'm not sure it is worth killing, given how
small and simple it is. No opinion on the other ones, though.
Is there a document around somewhere describing the 15000 different
virtual / nestable / pluggable X servers in / around X.Org and their
similarities and differences? If not, could somebody who knows please
write one?
Bart
On Mon, Mar 26, 2012 at 4:13 PM, Jeremy Huddleston <jeremyhu@apple.com> wrote:
> These need to die. This removes 30K lines of code from xorg-server. It must be good!
>
> Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs.
>
> Ok, you may now commence with the flinging of FUD.
>
> The following changes since commit a7eac500e652f30deffd9dc5e623fab701077738:
>
> Merge branch 'per-device-sync-counters' into for-keith (2012-03-22 13:13:07 +1000)
>
> are available in the git repository at:
>
>
> git://people.freedesktop.org/~jeremyhu/xserver puntage
>
> for you to fetch changes up to 71eba5bf1a56d2be2ac21bececd9371489deb016:
>
> Remove kdrive (2012-03-26 16:07:11 -0700)
>
> ----------------------------------------------------------------
> Jeremy Huddleston (2):
> Remove Xnest and Xvfb
> Remove kdrive
>
> configure.ac | 195 +---
> hw/Makefile.am | 17 +-
> hw/kdrive/Makefile.am | 30 -
> hw/kdrive/Xkdrive.man | 57 -
> hw/kdrive/ephyr/.gitignore | 1 -
> hw/kdrive/ephyr/Makefile.am | 90 --
> hw/kdrive/ephyr/README | 73 --
> hw/kdrive/ephyr/XF86dri.c | 647 -----------
> hw/kdrive/ephyr/ephyr.c | 1134 -------------------
> hw/kdrive/ephyr/ephyr.h | 198 ----
> hw/kdrive/ephyr/ephyr_draw.c | 531 ---------
> hw/kdrive/ephyr/ephyrdri.c | 270 -----
> hw/kdrive/ephyr/ephyrdri.h | 70 --
> hw/kdrive/ephyr/ephyrdriext.c | 1383 -----------------------
> hw/kdrive/ephyr/ephyrdriext.h | 40 -
> hw/kdrive/ephyr/ephyrglxext.c | 711 ------------
> hw/kdrive/ephyr/ephyrglxext.h | 34 -
> hw/kdrive/ephyr/ephyrhostglx.c | 683 ------------
> hw/kdrive/ephyr/ephyrhostglx.h | 71 --
> hw/kdrive/ephyr/ephyrhostproxy.c | 91 --
> hw/kdrive/ephyr/ephyrhostproxy.h | 51 -
> hw/kdrive/ephyr/ephyrhostvideo.c | 975 ----------------
> hw/kdrive/ephyr/ephyrhostvideo.h | 231 ----
> hw/kdrive/ephyr/ephyrinit.c | 393 -------
> hw/kdrive/ephyr/ephyrlog.h | 67 --
> hw/kdrive/ephyr/ephyrproxyext.c | 115 --
> hw/kdrive/ephyr/ephyrproxyext.h | 33 -
> hw/kdrive/ephyr/ephyrvideo.c | 1218 --------------------
> hw/kdrive/ephyr/hostx.c | 1375 -----------------------
> hw/kdrive/ephyr/hostx.h | 246 ----
> hw/kdrive/ephyr/man/Makefile.am | 2 -
> hw/kdrive/ephyr/man/Xephyr.man | 89 --
> hw/kdrive/ephyr/os.c | 49 -
> hw/kdrive/ephyr/xf86dri.h | 124 --
> hw/kdrive/fake/.gitignore | 2 -
> hw/kdrive/fake/Makefile.am | 30 -
> hw/kdrive/fake/fake.c | 450 --------
> hw/kdrive/fake/fake.h | 131 ---
> hw/kdrive/fake/fakeinit.c | 119 --
> hw/kdrive/fake/kbd.c | 75 --
> hw/kdrive/fake/mouse.c | 65 --
> hw/kdrive/fake/os.c | 62 -
> hw/kdrive/fbdev/.gitignore | 2 -
> hw/kdrive/fbdev/Makefile.am | 29 -
> hw/kdrive/fbdev/Xfbdev.man | 28 -
> hw/kdrive/fbdev/fbdev.c | 789 -------------
> hw/kdrive/fbdev/fbdev.h | 99 --
> hw/kdrive/fbdev/fbinit.c | 105 --
> hw/kdrive/linux/Makefile.am | 27 -
> hw/kdrive/linux/evdev.c | 519 ---------
> hw/kdrive/linux/keyboard.c | 782 -------------
> hw/kdrive/linux/linux.c | 372 ------
> hw/kdrive/linux/mouse.c | 1004 -----------------
> hw/kdrive/linux/ms.c | 178 ---
> hw/kdrive/linux/ps2.c | 180 ---
> hw/kdrive/linux/tslib.c | 195 ----
> hw/kdrive/src/Makefile.am | 28 -
> hw/kdrive/src/fourcc.h | 132 ---
> hw/kdrive/src/kcmap.c | 243 ----
> hw/kdrive/src/kdrive.c | 1121 -------------------
> hw/kdrive/src/kdrive.h | 604 ----------
> hw/kdrive/src/kinfo.c | 150 ---
> hw/kdrive/src/kinput.c | 2295 --------------------------------------
> hw/kdrive/src/kmode.c | 378 -------
> hw/kdrive/src/kshadow.c | 80 --
> hw/kdrive/src/kxv.c | 1891 -------------------------------
> hw/kdrive/src/kxv.h | 277 -----
> hw/vfb/.gitignore | 1 -
> hw/vfb/InitInput.c | 153 ---
> hw/vfb/InitOutput.c | 940 ----------------
> hw/vfb/Makefile.am | 34 -
> hw/vfb/man/Makefile.am | 2 -
> hw/vfb/man/Xvfb.man | 125 ---
> hw/xnest/.gitignore | 1 -
> hw/xnest/Args.c | 192 ----
> hw/xnest/Args.h | 38 -
> hw/xnest/Color.c | 493 --------
> hw/xnest/Color.h | 58 -
> hw/xnest/Cursor.c | 173 ---
> hw/xnest/Display.c | 213 ----
> hw/xnest/Display.h | 44 -
> hw/xnest/Drawable.h | 26 -
> hw/xnest/Events.c | 218 ----
> hw/xnest/Events.h | 29 -
> hw/xnest/Font.c | 88 --
> hw/xnest/GC.c | 328 ------
> hw/xnest/GCOps.c | 326 ------
> hw/xnest/GCOps.h | 68 --
> hw/xnest/Handlers.c | 45 -
> hw/xnest/Handlers.h | 22 -
> hw/xnest/Init.c | 156 ---
> hw/xnest/Init.h | 20 -
> hw/xnest/Keyboard.c | 267 -----
> hw/xnest/Keyboard.h | 28 -
> hw/xnest/Makefile.am | 72 --
> hw/xnest/Pixmap.c | 136 ---
> hw/xnest/Pointer.c | 96 --
> hw/xnest/Pointer.h | 29 -
> hw/xnest/Screen.c | 428 -------
> hw/xnest/Screen.h | 25 -
> hw/xnest/Visual.c | 70 --
> hw/xnest/Visual.h | 25 -
> hw/xnest/Window.c | 517 ---------
> hw/xnest/XNCursor.h | 52 -
> hw/xnest/XNFont.h | 34 -
> hw/xnest/XNGC.h | 43 -
> hw/xnest/XNPixmap.h | 38 -
> hw/xnest/XNWindow.h | 74 --
> hw/xnest/Xnest.h | 90 --
> hw/xnest/icon | 14 -
> hw/xnest/man/Makefile.am | 2 -
> hw/xnest/man/Xnest.man | 428 -------
> hw/xnest/screensaver | 686 ------------
> hw/xnest/xnest-config.h | 36 -
> include/kdrive-config.h.in | 40 -
> 115 files changed, 2 insertions(+), 30757 deletions(-)
> delete mode 100644 hw/kdrive/Makefile.am
> delete mode 100644 hw/kdrive/Xkdrive.man
> delete mode 100644 hw/kdrive/ephyr/.gitignore
> delete mode 100644 hw/kdrive/ephyr/Makefile.am
> delete mode 100644 hw/kdrive/ephyr/README
> delete mode 100644 hw/kdrive/ephyr/XF86dri.c
> delete mode 100644 hw/kdrive/ephyr/ephyr.c
> delete mode 100644 hw/kdrive/ephyr/ephyr.h
> delete mode 100644 hw/kdrive/ephyr/ephyr_draw.c
> delete mode 100644 hw/kdrive/ephyr/ephyrdri.c
> delete mode 100644 hw/kdrive/ephyr/ephyrdri.h
> delete mode 100644 hw/kdrive/ephyr/ephyrdriext.c
> delete mode 100644 hw/kdrive/ephyr/ephyrdriext.h
> delete mode 100644 hw/kdrive/ephyr/ephyrglxext.c
> delete mode 100644 hw/kdrive/ephyr/ephyrglxext.h
> delete mode 100644 hw/kdrive/ephyr/ephyrhostglx.c
> delete mode 100644 hw/kdrive/ephyr/ephyrhostglx.h
> delete mode 100644 hw/kdrive/ephyr/ephyrhostproxy.c
> delete mode 100644 hw/kdrive/ephyr/ephyrhostproxy.h
> delete mode 100644 hw/kdrive/ephyr/ephyrhostvideo.c
> delete mode 100644 hw/kdrive/ephyr/ephyrhostvideo.h
> delete mode 100644 hw/kdrive/ephyr/ephyrinit.c
> delete mode 100644 hw/kdrive/ephyr/ephyrlog.h
> delete mode 100644 hw/kdrive/ephyr/ephyrproxyext.c
> delete mode 100644 hw/kdrive/ephyr/ephyrproxyext.h
> delete mode 100644 hw/kdrive/ephyr/ephyrvideo.c
> delete mode 100644 hw/kdrive/ephyr/hostx.c
> delete mode 100644 hw/kdrive/ephyr/hostx.h
> delete mode 100644 hw/kdrive/ephyr/man/Makefile.am
> delete mode 100644 hw/kdrive/ephyr/man/Xephyr.man
> delete mode 100644 hw/kdrive/ephyr/os.c
> delete mode 100644 hw/kdrive/ephyr/xf86dri.h
> delete mode 100644 hw/kdrive/fake/.gitignore
> delete mode 100644 hw/kdrive/fake/Makefile.am
> delete mode 100644 hw/kdrive/fake/fake.c
> delete mode 100644 hw/kdrive/fake/fake.h
> delete mode 100644 hw/kdrive/fake/fakeinit.c
> delete mode 100644 hw/kdrive/fake/kbd.c
> delete mode 100644 hw/kdrive/fake/mouse.c
> delete mode 100644 hw/kdrive/fake/os.c
> delete mode 100644 hw/kdrive/fbdev/.gitignore
> delete mode 100644 hw/kdrive/fbdev/Makefile.am
> delete mode 100644 hw/kdrive/fbdev/Xfbdev.man
> delete mode 100644 hw/kdrive/fbdev/fbdev.c
> delete mode 100644 hw/kdrive/fbdev/fbdev.h
> delete mode 100644 hw/kdrive/fbdev/fbinit.c
> delete mode 100644 hw/kdrive/linux/Makefile.am
> delete mode 100644 hw/kdrive/linux/evdev.c
> delete mode 100644 hw/kdrive/linux/keyboard.c
> delete mode 100644 hw/kdrive/linux/linux.c
> delete mode 100644 hw/kdrive/linux/mouse.c
> delete mode 100644 hw/kdrive/linux/ms.c
> delete mode 100644 hw/kdrive/linux/ps2.c
> delete mode 100644 hw/kdrive/linux/tslib.c
> delete mode 100644 hw/kdrive/src/Makefile.am
> delete mode 100644 hw/kdrive/src/fourcc.h
> delete mode 100644 hw/kdrive/src/kcmap.c
> delete mode 100644 hw/kdrive/src/kdrive.c
> delete mode 100644 hw/kdrive/src/kdrive.h
> delete mode 100644 hw/kdrive/src/kinfo.c
> delete mode 100644 hw/kdrive/src/kinput.c
> delete mode 100644 hw/kdrive/src/kmode.c
> delete mode 100644 hw/kdrive/src/kshadow.c
> delete mode 100644 hw/kdrive/src/kxv.c
> delete mode 100644 hw/kdrive/src/kxv.h
> delete mode 100644 hw/vfb/.gitignore
> delete mode 100644 hw/vfb/InitInput.c
> delete mode 100644 hw/vfb/InitOutput.c
> delete mode 100644 hw/vfb/Makefile.am
> delete mode 100644 hw/vfb/man/Makefile.am
> delete mode 100644 hw/vfb/man/Xvfb.man
> delete mode 100644 hw/xnest/.gitignore
> delete mode 100644 hw/xnest/Args.c
> delete mode 100644 hw/xnest/Args.h
> delete mode 100644 hw/xnest/Color.c
> delete mode 100644 hw/xnest/Color.h
> delete mode 100644 hw/xnest/Cursor.c
> delete mode 100644 hw/xnest/Display.c
> delete mode 100644 hw/xnest/Display.h
> delete mode 100644 hw/xnest/Drawable.h
> delete mode 100644 hw/xnest/Events.c
> delete mode 100644 hw/xnest/Events.h
> delete mode 100644 hw/xnest/Font.c
> delete mode 100644 hw/xnest/GC.c
> delete mode 100644 hw/xnest/GCOps.c
> delete mode 100644 hw/xnest/GCOps.h
> delete mode 100644 hw/xnest/Handlers.c
> delete mode 100644 hw/xnest/Handlers.h
> delete mode 100644 hw/xnest/Init.c
> delete mode 100644 hw/xnest/Init.h
> delete mode 100644 hw/xnest/Keyboard.c
> delete mode 100644 hw/xnest/Keyboard.h
> delete mode 100644 hw/xnest/Makefile.am
> delete mode 100644 hw/xnest/Pixmap.c
> delete mode 100644 hw/xnest/Pointer.c
> delete mode 100644 hw/xnest/Pointer.h
> delete mode 100644 hw/xnest/Screen.c
> delete mode 100644 hw/xnest/Screen.h
> delete mode 100644 hw/xnest/Visual.c
> delete mode 100644 hw/xnest/Visual.h
> delete mode 100644 hw/xnest/Window.c
> delete mode 100644 hw/xnest/XNCursor.h
> delete mode 100644 hw/xnest/XNFont.h
> delete mode 100644 hw/xnest/XNGC.h
> delete mode 100644 hw/xnest/XNPixmap.h
> delete mode 100644 hw/xnest/XNWindow.h
> delete mode 100644 hw/xnest/Xnest.h
> delete mode 100644 hw/xnest/icon
> delete mode 100644 hw/xnest/man/Makefile.am
> delete mode 100644 hw/xnest/man/Xnest.man
> delete mode 100644 hw/xnest/screensaver
> delete mode 100644 hw/xnest/xnest-config.h
> delete mode 100644 include/kdrive-config.h.in
>
>
> _______________________________________________
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
On 2012-03-26 23:09, Jamey Sharp wrote: > On Mon, Mar 26, 2012 at 6:31 PM, Yaakov (Cygwin/X) wrote: >> 1. Will Xorg even work on Cygwin/MinGW? (I would ask the same of OS X, but >> as the Xquartz maintainer I suppose you know what you are doing.) Even if it >> does, I see already it would take some serious patching to build due to the >> module-based architecture, which I would be willing to work on. > > Ah, that's a good point. Jeremy took care of the issues with running > Xorg on OS X during the 1.12 cycle, but that needs to happen for > Windows too. I'm hopeful that at least some of the work he did will > make that job easier. I've already got a patchset for Cygwin. As for MinGW, while many of the buildsystem issues are the same, there's the question of porting the code (loader and posix_tty jump to mind). Yaakov Cygwin/X
On 27/03/2012 05:09, Jamey Sharp wrote: > However, our capstone project that just finished was a start toward > replacing the XQuartz DDX with a stock Xorg server and a special > client, and I'm hoping that XWin can go the same direction. This is certainly the approach I'd like to take, as well, rather than stuffing all the WM integration code into a client thread inside the X server. However, replacing the Win32 native XWin (as opposed to an XWin built to use the cygwin layer) with the Xorg DDX seems like it would involve a non-trivial amount of work, in effectively porting the Xorg DDX to the Win32 API. > The special client acts something like a compositing window manager. > It's pretty alpha right now, but proves the concept nicely on OS X. It > was designed to have a portable core library shared by several > applications, one for each native window system (say, OS X, Windows, > and Wayland). Now would be a great time to start generalizing to other > window systems. > > http://cgit.freedesktop.org/xorg/lib/libxcwm/ Thanks. I know you have mentioned this project previously and I'll try to make the time to take a look at it. Is there a way to support hardware-accelerated GL in that arrangement?
On Tue, Apr 3, 2012 at 4:41 AM, Jon TURNEY <jon.turney@dronecode.org.uk> wrote: > On 27/03/2012 05:09, Jamey Sharp wrote: >> However, our capstone project that just finished was a start toward >> replacing the XQuartz DDX with a stock Xorg server and a special >> client, and I'm hoping that XWin can go the same direction. > > This is certainly the approach I'd like to take, as well, rather than stuffing > all the WM integration code into a client thread inside the X server. > > However, replacing the Win32 native XWin (as opposed to an XWin built to use > the cygwin layer) with the Xorg DDX seems like it would involve a non-trivial > amount of work, in effectively porting the Xorg DDX to the Win32 API. I'd be really interested to know how much of the Xorg DDX relies on POSIX and how much is straight C. The module loader is an obvious candidate for pain, but once you turn off stuff like the PCI layer that doesn't matter on Windows, how much non-portable stuff is left? I'm going to propose another student capstone project in a couple of weeks, and I haven't actually decided what to ask the students for yet. If you can sort out pretty soon how much work is really involved here, we could try getting a team of five or six students to do it over the next six months. If we go that direction, I'd also need one or two XWin developers to co-sponsor the project with me, committing to being available for the platform-specific questions I can't answer. It'd help if you could get to Portland at least once during the project, too... >> http://cgit.freedesktop.org/xorg/lib/libxcwm/ > > Thanks. I know you have mentioned this project previously and I'll try to > make the time to take a look at it. Much appreciated! > Is there a way to support hardware-accelerated GL in that arrangement? I hope so. :-) First, write Mesa and Xorg video driver bits that use the platform-native accelerated rendering APIs, but only allocate off-screen video memory, even for Window objects. If you can do DRI-like 3D rendering on Windows, then at least the really expensive part of 3D rendering can be accelerated, even if the libxcwm-based client still uses GetImage to read back the results. (For extra bonus points, use the glamor library in this driver to hardware-accelerate 2D rendering as well. Wheee!) After that, if you can also provide an OpenGL texture-from-pixmap extension, then libxcwm can replace the slow GetImage path with a hardware-accelerated blit from the back-buffers the server owns to the native windows created by the libxcwm-based client. Combined with the Composite extension's NameWindowPixmap request, this is just like a GL compositor such as Compiz. That gets you fast updates of any rendering, 2D or 3D, onto the real display. Implementing texture-from-pixmap is the tricky part, because it requires that processes in different address spaces be permitted to share textures. Linux DRI can do that; Jeremy tells me that given the public APIs on OS X, it's tricky at best. Does Windows allow it? Jamey
On 2012-04-03 13:58, Jamey Sharp wrote: > I'd be really interested to know how much of the Xorg DDX relies on > POSIX and how much is straight C. The module loader is an obvious > candidate for pain, but once you turn off stuff like the PCI layer > that doesn't matter on Windows, how much non-portable stuff is left? Hard to say; I got as far as building libX11 for mingw32 when: CC ClDisplay.lo In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:48:0, from /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h:22, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb_windefs.h:34, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb.h:41, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/include/X11/Xlib-xcb.h:7, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/Xxcbint.h:10, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/ClDisplay.c:33: /usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:234:17: error: conflicting types for ‘BOOL’ /usr/i686-pc-mingw32/sys-root/mingw/include/X11/Xmd.h:143:16: note: previous declaration of ‘BOOL’ was here In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/winnt.h:192:0, from /usr/i686-pc-mingw32/sys-root/mingw/include/windef.h:253, from /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:48, from /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h:22, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb_windefs.h:34, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb.h:41, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/include/X11/Xlib-xcb.h:7, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/Xxcbint.h:10, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/ClDisplay.c:33: /usr/i686-pc-mingw32/sys-root/mingw/include/basetsd.h:54:13: error: conflicting types for ‘INT32’ /usr/i686-pc-mingw32/sys-root/mingw/include/X11/Xmd.h:120:14: note: previous declaration of ‘INT32’ was here In file included from /usr/i686-pc-mingw32/sys-root/mingw/include/windows.h:87:0, from /usr/i686-pc-mingw32/sys-root/mingw/include/winsock2.h:22, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb_windefs.h:34, from /usr/i686-pc-mingw32/sys-root/mingw/include/xcb/xcb.h:41, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/include/X11/Xlib-xcb.h:7, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/Xxcbint.h:10, from /usr/src/ports/mingw-libX11/mingw-libX11-1.4.4-1/src/libX11-1.4.4/src/ClDisplay.c:33: /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:255:8: error: two or more data types in declaration specifiers /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:270:8: error: two or more data types in declaration specifiers /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:291:8: error: two or more data types in declaration specifiers /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:316:8: error: two or more data types in declaration specifiers /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:571:8: error: two or more data types in declaration specifiers /usr/i686-pc-mingw32/sys-root/mingw/include/winspool.h:594:8: error: two or more data types in declaration specifiers Makefile:965: recipe for target `ClDisplay.lo' failed make[3]: *** [ClDisplay.lo] Error 1 Yaakov Cygwin/X
On 04/ 3/12 11:58 AM, Jamey Sharp wrote: > On Tue, Apr 3, 2012 at 4:41 AM, Jon TURNEY <jon.turney@dronecode.org.uk> wrote: >> On 27/03/2012 05:09, Jamey Sharp wrote: >>> However, our capstone project that just finished was a start toward >>> replacing the XQuartz DDX with a stock Xorg server and a special >>> client, and I'm hoping that XWin can go the same direction. >> >> This is certainly the approach I'd like to take, as well, rather than stuffing >> all the WM integration code into a client thread inside the X server. >> >> However, replacing the Win32 native XWin (as opposed to an XWin built to use >> the cygwin layer) with the Xorg DDX seems like it would involve a non-trivial >> amount of work, in effectively porting the Xorg DDX to the Win32 API. > > I'd be really interested to know how much of the Xorg DDX relies on > POSIX and how much is straight C. Relying on POSIX would be far more portable than it really is - there's lots of non-standardized interfaces in there. (Not even counting os-support/* which is where most things that are utterly kernel specific and non-portable ended up.)
On 03/04/2012 22:08, Yaakov Selkowitz wrote: > On 2012-04-03 13:58, Jamey Sharp wrote: >> I'd be really interested to know how much of the Xorg DDX relies on >> POSIX and how much is straight C. The module loader is an obvious >> candidate for pain, but once you turn off stuff like the PCI layer >> that doesn't matter on Windows, how much non-portable stuff is left? > > Hard to say; I got as far as building libX11 for mingw32 when: At the moment, substantial patching is required to build X for mingw32. Even the XWin DDX does not build for the mingw32 target out of the box. Fortunately, Ryan Pavlik has done all this work already, see [1]. Unfortunately I've been a bit slack in pushing this work upstream :-( [1] https://github.com/rpavlik/Xserver/tree/cleanpatches-1.11-branch
These need to die. This removes 30K lines of code from xorg-server. It must be good! Most functionality of these servers can be provide by Xorg with either the nested or dummy video driver. If someone really misses functionality, we should fix that deficiency in hw/xfree86, xf86-video-dummy, or xf86-video-nested. Also, there's nothing stopping anyone from using older server versions if they still need these DDXs. Ok, you may now commence with the flinging of FUD. The following changes since commit a7eac500e652f30deffd9dc5e623fab701077738: Merge branch 'per-device-sync-counters' into for-keith (2012-03-22 13:13:07 +1000) are available in the git repository at: git://people.freedesktop.org/~jeremyhu/xserver puntage for you to fetch changes up to 71eba5bf1a56d2be2ac21bececd9371489deb016: Remove kdrive (2012-03-26 16:07:11 -0700) ---------------------------------------------------------------- Jeremy Huddleston (2): Remove Xnest and Xvfb Remove kdrive configure.ac | 195 +--- hw/Makefile.am | 17 +- hw/kdrive/Makefile.am | 30 - hw/kdrive/Xkdrive.man | 57 - hw/kdrive/ephyr/.gitignore | 1 - hw/kdrive/ephyr/Makefile.am | 90 -- hw/kdrive/ephyr/README | 73 -- hw/kdrive/ephyr/XF86dri.c | 647 ----------- hw/kdrive/ephyr/ephyr.c | 1134 ------------------- hw/kdrive/ephyr/ephyr.h | 198 ---- hw/kdrive/ephyr/ephyr_draw.c | 531 --------- hw/kdrive/ephyr/ephyrdri.c | 270 ----- hw/kdrive/ephyr/ephyrdri.h | 70 -- hw/kdrive/ephyr/ephyrdriext.c | 1383 ----------------------- hw/kdrive/ephyr/ephyrdriext.h | 40 - hw/kdrive/ephyr/ephyrglxext.c | 711 ------------ hw/kdrive/ephyr/ephyrglxext.h | 34 - hw/kdrive/ephyr/ephyrhostglx.c | 683 ------------ hw/kdrive/ephyr/ephyrhostglx.h | 71 -- hw/kdrive/ephyr/ephyrhostproxy.c | 91 -- hw/kdrive/ephyr/ephyrhostproxy.h | 51 - hw/kdrive/ephyr/ephyrhostvideo.c | 975 ---------------- hw/kdrive/ephyr/ephyrhostvideo.h | 231 ---- hw/kdrive/ephyr/ephyrinit.c | 393 ------- hw/kdrive/ephyr/ephyrlog.h | 67 -- hw/kdrive/ephyr/ephyrproxyext.c | 115 -- hw/kdrive/ephyr/ephyrproxyext.h | 33 - hw/kdrive/ephyr/ephyrvideo.c | 1218 -------------------- hw/kdrive/ephyr/hostx.c | 1375 ----------------------- hw/kdrive/ephyr/hostx.h | 246 ---- hw/kdrive/ephyr/man/Makefile.am | 2 - hw/kdrive/ephyr/man/Xephyr.man | 89 -- hw/kdrive/ephyr/os.c | 49 - hw/kdrive/ephyr/xf86dri.h | 124 -- hw/kdrive/fake/.gitignore | 2 - hw/kdrive/fake/Makefile.am | 30 - hw/kdrive/fake/fake.c | 450 -------- hw/kdrive/fake/fake.h | 131 --- hw/kdrive/fake/fakeinit.c | 119 -- hw/kdrive/fake/kbd.c | 75 -- hw/kdrive/fake/mouse.c | 65 -- hw/kdrive/fake/os.c | 62 - hw/kdrive/fbdev/.gitignore | 2 - hw/kdrive/fbdev/Makefile.am | 29 - hw/kdrive/fbdev/Xfbdev.man | 28 - hw/kdrive/fbdev/fbdev.c | 789 ------------- hw/kdrive/fbdev/fbdev.h | 99 -- hw/kdrive/fbdev/fbinit.c | 105 -- hw/kdrive/linux/Makefile.am | 27 - hw/kdrive/linux/evdev.c | 519 --------- hw/kdrive/linux/keyboard.c | 782 ------------- hw/kdrive/linux/linux.c | 372 ------ hw/kdrive/linux/mouse.c | 1004 ----------------- hw/kdrive/linux/ms.c | 178 --- hw/kdrive/linux/ps2.c | 180 --- hw/kdrive/linux/tslib.c | 195 ---- hw/kdrive/src/Makefile.am | 28 - hw/kdrive/src/fourcc.h | 132 --- hw/kdrive/src/kcmap.c | 243 ---- hw/kdrive/src/kdrive.c | 1121 ------------------- hw/kdrive/src/kdrive.h | 604 ---------- hw/kdrive/src/kinfo.c | 150 --- hw/kdrive/src/kinput.c | 2295 -------------------------------------- hw/kdrive/src/kmode.c | 378 ------- hw/kdrive/src/kshadow.c | 80 -- hw/kdrive/src/kxv.c | 1891 ------------------------------- hw/kdrive/src/kxv.h | 277 ----- hw/vfb/.gitignore | 1 - hw/vfb/InitInput.c | 153 --- hw/vfb/InitOutput.c | 940 ---------------- hw/vfb/Makefile.am | 34 - hw/vfb/man/Makefile.am | 2 - hw/vfb/man/Xvfb.man | 125 --- hw/xnest/.gitignore | 1 - hw/xnest/Args.c | 192 ---- hw/xnest/Args.h | 38 - hw/xnest/Color.c | 493 -------- hw/xnest/Color.h | 58 - hw/xnest/Cursor.c | 173 --- hw/xnest/Display.c | 213 ---- hw/xnest/Display.h | 44 - hw/xnest/Drawable.h | 26 - hw/xnest/Events.c | 218 ---- hw/xnest/Events.h | 29 - hw/xnest/Font.c | 88 -- hw/xnest/GC.c | 328 ------ hw/xnest/GCOps.c | 326 ------ hw/xnest/GCOps.h | 68 -- hw/xnest/Handlers.c | 45 - hw/xnest/Handlers.h | 22 - hw/xnest/Init.c | 156 --- hw/xnest/Init.h | 20 - hw/xnest/Keyboard.c | 267 ----- hw/xnest/Keyboard.h | 28 - hw/xnest/Makefile.am | 72 -- hw/xnest/Pixmap.c | 136 --- hw/xnest/Pointer.c | 96 -- hw/xnest/Pointer.h | 29 - hw/xnest/Screen.c | 428 ------- hw/xnest/Screen.h | 25 - hw/xnest/Visual.c | 70 -- hw/xnest/Visual.h | 25 - hw/xnest/Window.c | 517 --------- hw/xnest/XNCursor.h | 52 - hw/xnest/XNFont.h | 34 - hw/xnest/XNGC.h | 43 - hw/xnest/XNPixmap.h | 38 - hw/xnest/XNWindow.h | 74 -- hw/xnest/Xnest.h | 90 -- hw/xnest/icon | 14 - hw/xnest/man/Makefile.am | 2 - hw/xnest/man/Xnest.man | 428 ------- hw/xnest/screensaver | 686 ------------ hw/xnest/xnest-config.h | 36 - include/kdrive-config.h.in | 40 - 115 files changed, 2 insertions(+), 30757 deletions(-) delete mode 100644 hw/kdrive/Makefile.am delete mode 100644 hw/kdrive/Xkdrive.man delete mode 100644 hw/kdrive/ephyr/.gitignore delete mode 100644 hw/kdrive/ephyr/Makefile.am delete mode 100644 hw/kdrive/ephyr/README delete mode 100644 hw/kdrive/ephyr/XF86dri.c delete mode 100644 hw/kdrive/ephyr/ephyr.c delete mode 100644 hw/kdrive/ephyr/ephyr.h delete mode 100644 hw/kdrive/ephyr/ephyr_draw.c delete mode 100644 hw/kdrive/ephyr/ephyrdri.c delete mode 100644 hw/kdrive/ephyr/ephyrdri.h delete mode 100644 hw/kdrive/ephyr/ephyrdriext.c delete mode 100644 hw/kdrive/ephyr/ephyrdriext.h delete mode 100644 hw/kdrive/ephyr/ephyrglxext.c delete mode 100644 hw/kdrive/ephyr/ephyrglxext.h delete mode 100644 hw/kdrive/ephyr/ephyrhostglx.c delete mode 100644 hw/kdrive/ephyr/ephyrhostglx.h delete mode 100644 hw/kdrive/ephyr/ephyrhostproxy.c delete mode 100644 hw/kdrive/ephyr/ephyrhostproxy.h delete mode 100644 hw/kdrive/ephyr/ephyrhostvideo.c delete mode 100644 hw/kdrive/ephyr/ephyrhostvideo.h delete mode 100644 hw/kdrive/ephyr/ephyrinit.c delete mode 100644 hw/kdrive/ephyr/ephyrlog.h delete mode 100644 hw/kdrive/ephyr/ephyrproxyext.c delete mode 100644 hw/kdrive/ephyr/ephyrproxyext.h delete mode 100644 hw/kdrive/ephyr/ephyrvideo.c delete mode 100644 hw/kdrive/ephyr/hostx.c delete mode 100644 hw/kdrive/ephyr/hostx.h delete mode 100644 hw/kdrive/ephyr/man/Makefile.am delete mode 100644 hw/kdrive/ephyr/man/Xephyr.man delete mode 100644 hw/kdrive/ephyr/os.c delete mode 100644 hw/kdrive/ephyr/xf86dri.h delete mode 100644 hw/kdrive/fake/.gitignore delete mode 100644 hw/kdrive/fake/Makefile.am delete mode 100644 hw/kdrive/fake/fake.c delete mode 100644 hw/kdrive/fake/fake.h delete mode 100644 hw/kdrive/fake/fakeinit.c delete mode 100644 hw/kdrive/fake/kbd.c delete mode 100644 hw/kdrive/fake/mouse.c delete mode 100644 hw/kdrive/fake/os.c delete mode 100644 hw/kdrive/fbdev/.gitignore delete mode 100644 hw/kdrive/fbdev/Makefile.am delete mode 100644 hw/kdrive/fbdev/Xfbdev.man delete mode 100644 hw/kdrive/fbdev/fbdev.c delete mode 100644 hw/kdrive/fbdev/fbdev.h delete mode 100644 hw/kdrive/fbdev/fbinit.c delete mode 100644 hw/kdrive/linux/Makefile.am delete mode 100644 hw/kdrive/linux/evdev.c delete mode 100644 hw/kdrive/linux/keyboard.c delete mode 100644 hw/kdrive/linux/linux.c delete mode 100644 hw/kdrive/linux/mouse.c delete mode 100644 hw/kdrive/linux/ms.c delete mode 100644 hw/kdrive/linux/ps2.c delete mode 100644 hw/kdrive/linux/tslib.c delete mode 100644 hw/kdrive/src/Makefile.am delete mode 100644 hw/kdrive/src/fourcc.h delete mode 100644 hw/kdrive/src/kcmap.c delete mode 100644 hw/kdrive/src/kdrive.c delete mode 100644 hw/kdrive/src/kdrive.h delete mode 100644 hw/kdrive/src/kinfo.c delete mode 100644 hw/kdrive/src/kinput.c delete mode 100644 hw/kdrive/src/kmode.c delete mode 100644 hw/kdrive/src/kshadow.c delete mode 100644 hw/kdrive/src/kxv.c delete mode 100644 hw/kdrive/src/kxv.h delete mode 100644 hw/vfb/.gitignore delete mode 100644 hw/vfb/InitInput.c delete mode 100644 hw/vfb/InitOutput.c delete mode 100644 hw/vfb/Makefile.am delete mode 100644 hw/vfb/man/Makefile.am delete mode 100644 hw/vfb/man/Xvfb.man delete mode 100644 hw/xnest/.gitignore delete mode 100644 hw/xnest/Args.c delete mode 100644 hw/xnest/Args.h delete mode 100644 hw/xnest/Color.c delete mode 100644 hw/xnest/Color.h delete mode 100644 hw/xnest/Cursor.c delete mode 100644 hw/xnest/Display.c delete mode 100644 hw/xnest/Display.h delete mode 100644 hw/xnest/Drawable.h delete mode 100644 hw/xnest/Events.c delete mode 100644 hw/xnest/Events.h delete mode 100644 hw/xnest/Font.c delete mode 100644 hw/xnest/GC.c delete mode 100644 hw/xnest/GCOps.c delete mode 100644 hw/xnest/GCOps.h delete mode 100644 hw/xnest/Handlers.c delete mode 100644 hw/xnest/Handlers.h delete mode 100644 hw/xnest/Init.c delete mode 100644 hw/xnest/Init.h delete mode 100644 hw/xnest/Keyboard.c delete mode 100644 hw/xnest/Keyboard.h delete mode 100644 hw/xnest/Makefile.am delete mode 100644 hw/xnest/Pixmap.c delete mode 100644 hw/xnest/Pointer.c delete mode 100644 hw/xnest/Pointer.h delete mode 100644 hw/xnest/Screen.c delete mode 100644 hw/xnest/Screen.h delete mode 100644 hw/xnest/Visual.c delete mode 100644 hw/xnest/Visual.h delete mode 100644 hw/xnest/Window.c delete mode 100644 hw/xnest/XNCursor.h delete mode 100644 hw/xnest/XNFont.h delete mode 100644 hw/xnest/XNGC.h delete mode 100644 hw/xnest/XNPixmap.h delete mode 100644 hw/xnest/XNWindow.h delete mode 100644 hw/xnest/Xnest.h delete mode 100644 hw/xnest/icon delete mode 100644 hw/xnest/man/Makefile.am delete mode 100644 hw/xnest/man/Xnest.man delete mode 100644 hw/xnest/screensaver delete mode 100644 hw/xnest/xnest-config.h delete mode 100644 include/kdrive-config.h.in