Patchwork [PULL,to,discuss] Remove kdrive, Xnest, and Xvfb

login
register
mail settings
Submitter Jeremy Huddleston
Date March 26, 2012, 11:13 p.m.
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 puntage

Comments

Jeremy Huddleston - March 26, 2012, 11:13 p.m.
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
Keith Packard - March 26, 2012, 11:31 p.m.
<#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?
Sérgio Basto - March 26, 2012, 11:39 p.m.
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,
Jamey Sharp - March 26, 2012, 11:55 p.m.
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
Sérgio Basto - March 26, 2012, 11:59 p.m.
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
Sérgio Basto - March 27, 2012, 12:09 a.m.
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,
Chase Douglas - March 27, 2012, 12:09 a.m.
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!
Jamey Sharp - March 27, 2012, 12:37 a.m.
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
Jamey Sharp - March 27, 2012, 12:50 a.m.
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
Alan Coopersmith - March 27, 2012, 1:01 a.m.
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).
Chase Douglas - March 27, 2012, 1:16 a.m.
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
Yaakov Selkowitz - March 27, 2012, 1:31 a.m.
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
Alan Coopersmith - March 27, 2012, 2:37 a.m.
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.
Jeremy Huddleston - March 27, 2012, 2:46 a.m.
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.
Jeremy Huddleston - March 27, 2012, 2:50 a.m.
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").
Alan Coopersmith - March 27, 2012, 3:09 a.m.
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?
Jamey Sharp - March 27, 2012, 3:21 a.m.
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
Alan Coopersmith - March 27, 2012, 3:30 a.m.
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.
Jamey Sharp - March 27, 2012, 4:07 a.m.
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
Jamey Sharp - March 27, 2012, 4:09 a.m.
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
Alan Coopersmith - March 27, 2012, 5:06 a.m.
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.
Matthieu Herrb - March 27, 2012, 6:10 a.m.
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.
Yaakov Selkowitz - March 27, 2012, 6:56 a.m.
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
Michel Dänzer - March 27, 2012, 7:08 a.m.
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
Mikhail Gusarov - March 27, 2012, 7:31 a.m.
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

--
Antoine Martin - March 27, 2012, 7:54 a.m.
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
>
Antoine Martin - March 27, 2012, 8:06 a.m.
(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
Jamey Sharp - March 27, 2012, 1:03 p.m.
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
Mark Kettenis - March 27, 2012, 1:47 p.m.
> 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.
Jamey Sharp - March 27, 2012, 2:35 p.m.
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
Alan Coopersmith - March 27, 2012, 4:02 p.m.
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.
Sérgio Basto - March 27, 2012, 5:17 p.m.
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,
Jeremy Huddleston - March 27, 2012, 5:34 p.m.
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
Jamey Sharp - March 27, 2012, 5:46 p.m.
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
Alan Coopersmith - March 27, 2012, 5:53 p.m.
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.
Sérgio Basto - March 27, 2012, 6:02 p.m.
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,
Sérgio Basto - March 27, 2012, 6:36 p.m.
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
Antoine Martin - March 27, 2012, 6:42 p.m.
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.
Julien Cristau - March 27, 2012, 6:49 p.m.
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
Alan Coopersmith - March 27, 2012, 7:28 p.m.
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.
Yaakov Selkowitz - March 27, 2012, 8:12 p.m.
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
Derek Fawcus - March 27, 2012, 10:11 p.m.
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
Bart Massey - March 28, 2012, 9:15 p.m.
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
Yaakov Selkowitz - March 29, 2012, 9:16 a.m.
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
Jon TURNEY - April 3, 2012, 11:41 a.m.
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?
Jamey Sharp - April 3, 2012, 6:58 p.m.
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
Yaakov Selkowitz - April 3, 2012, 9:08 p.m.
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
Alan Coopersmith - April 4, 2012, 3:49 a.m.
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.)
Jon TURNEY - April 25, 2012, 12:24 p.m.
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