Some ideas

Richard Brown rbrown1445 at
Mon Mar 1 09:46:58 PST 2010

I will respond to both Alan Coopersmith and Alan Cox in this letter:

Alan Cox wrote:
>> This already exists, it's just not bundled with X.Org due to the different
>> license - TigerVNC uses current Xorg sources to build both Xvnc and a
>> loadable extension module that are compatible with current servers
>> and extensions.
> (Providing you don't have any non GPL compatible drivers loaded - eg some
> vendors binary only ones...)
> You don't actually need so urgently with the damage/compositing
> extensions because you've got a pretty good idea what needs adjusting.
> X11vnc is quite passable without being part of the server.
I have used x11vnc. It is not passable for me anyway. It is very slow 
compared to the snappy response i get with Xvnc. But Xvnc couldnt export 
the session that is on my local display. One of the big problems with 
x11vnc was the delay between typing and seeing the characters on the 
screen, i rely on the visual feedback when typing so it really made it 
hard for me to type. I currently use RealVNC's Xvnc but have always have 
thought having a vnc server in the main x server woiuld be better . I 
tried Tightvnc's Xvnc but found it very lacking, it didnt support 
several X extensions , which resulted in several X apps not display 

I will try tigervnc, it sounds like what i have been looking for . 
Thanks for that suggestion, Alan Coopersmith.
>>> 2) Low priority: Dynamic runtime loadable and unloadable drivers.
> With
>>> the possibility of hot pluggable devices, has this been considered? 
>> Already done for input devices.   Graphics is harder, but do you really
>> have systems where you're often hotplugging PCI-E cards while the system
>> is running?   (Yes, I know about USB-connected DisplayLink devices, but
>> most work around hotplugging those has been configuring them as separate
>> X seats/sessions, not incorporating them into a running server.)
> Unfortunately - although to use them properly is tricky anyway as the
> expectation is that the main video card composites the image in off
> screen ram and you then fire at at the USB, possibly using nutty 3D card
> hacks on the way to work out which chunks changed. That means you are
> trying to allocate resources on one device for rendering for another.
> Doubly fun if you hotplug the device doing the rendering work.
> Some of this also needs kernel work - being able to give up a device and
> claim a device reliably when it is being passed between users requires a
> couple of bits the Linux kernel currently lacks except for tty devices.
> This is much of the same stuff you need to run X as the user not as its
> own user or root.
This may not be not important for video cards at this time. In the 
future of plugin USB display devices (NTSC or ATSC out to a TV for 
instance) became popular (they may already be out there, though most use 
VGA out) it might have some value, but those would also be useable with 
a restart if such things became popular. Still the hotplug would be a plus.
> Alan
> _______________________________________________
> xorg mailing list
> xorg at

More information about the xorg mailing list