Re: Future features (was Re: Discussing issues)

On Wed, Apr 16, 2003 at 03:59:08PM -0400, Havoc Pennington wrote:
> On Wed, Apr 16, 2003 at 07:52:54PM +0100, Alan Hourihane wrote: 
> > When forum was started I posted a list of what the core team had talked
> > about as things we may do for XFree86 5.0. By no means is this a fixed
> > list or guaranteed. It was to open up discussion on what people are 
> > interested in doing for the next major release.
> > 
> > If you read that Havoc I think it'll give you an idea on where we
> > think we're heading, but please throw in some ideas on what else you
> > think needs to happen. Maybe someone with that itch would step forward
> > and write it, or has already been thinking the same thing.
> > 
> > Roll on discussion of where we're all heading in future features and
> > we'll all get a better picture of what's happening around us. I'm sure
> > we'll all come to like each other a lot more if we can be productive
> > in this type of communication.
> 
> Cool, the link for convenience:
>   http://www.xfree86.org/pipermail/forum/2003-March/000004.html 
> 
> Some things I can think of offhand to add:
> 
>  - for accessibility and some UI stuff a thumbnail/magnification 
>    extension. Keith has proposed doing this as part of the same 
>    code changes needed for alpha channels on windows.
> 
>    This is something I was trying to quickly address with the DAMAGE
>    extension I posted a while back. The reply I got on that extension 
>    was from Keith and he said my extension shouldn't be included 
>    because his bigger-picture changes would provide the same
>    functionality more generally.
 
O.k. Is Keith still pursueing this Havoc ?

>  - related to hot plug there's a general issue that the
>    desktop/application layer needs to track all the devices connected
>    to a system, whether they are enabled/disabled, etc. and provide 
>    appropriate UI
> 
>    I've been advocating a "hardware abstraction layer" for a while 
>    that would essentially be a shared library that manages 
>    a list of Device objects and tells an application when a device
>    comes and goes. A "Device" in this context on Linux is basically 
>    a major/minor pair as I understand it, i.e. a virtual device 
>    that already has a driver loaded.
> 
>    However, the hardware abstraction layer should be cross-platform.
> 
>    I would say that loading the driver is the domain of the operating
>    system, and apps/desktop only care about devices the OS has already
>    "found."
> 
>    For implementing the backend of this library, and perhaps 
>    for coordinating device usage among various X servers, 
>    I think D-BUS could be very useful. See 
>    http://www.freedesktop.org/software/dbus/
> 
>    This has also been discussed a bit in relation to Linux hotplug.
>    However it's important to understand (if I have this right) that
>    Linux hotplug is something that happens before a driver for a
>    device is loaded, and most things we probably care about happen
>    after a driver is loaded.
> 
>    I have some more extensive thoughts on this written down but 
>    they're written down in pretty rough form.
> 
>    Anyway, I don't know if XFree86 wants to try to look at this more
>    globally or if just a mouse/keyboard specific fairly limited
>    codebase is the right way to go. However, if there's a UI that
>    lists the devices on your system and the user can specify there
>    that "this USB device is a keyboard," I would think as soon as the
>    user identifies the device as a keyboard that X should pick it up -
>    ideally without even restarting the server.  So it would be nice if
>    we had *one* place on the system that said "USB device XYZ is a
>    keyboard" - and if in this place, the XYZ<->keyboard mapping could
>    be established by either an OS vendor, an OEM, or a local user
>    site.
> 
>    Some related threads:
>  http://sourceforge.net/mailarchive/forum.php?thread_id=1948705&forum_id=3157
>  https://listman.redhat.com/pipermail/message-bus-list/2003-April/000222.html
 
There are other issues with hotplug too. In the case of multiseat - i.e.
multiple Xservers running on the same machine with different graphics
hardware and utilizing different keyboards & mice. If a mouse gets plugged
in, which Xserver gets ownership of the device ? There needs to be a policy
manager that allows new hotplugged hardware to be connected (or offered)
to the Xserver.

>  - right now we have a bunch of keymaps that come with the GNOME
>    keyboard switcher applet.
> 
>    I think the idea of a "Swedish keyboard keymap" should probably 
>    come with X instead, so that these little applets are just 
>    a GUI widget that sends some request to the server or invoke 
>    some library. Then there's only one place you have to fix the
>    keymap.
>
>    I don't know a lot about this, I just see the keymaps coming with
>    an applet and think "gee that is really wrong" ;-) maybe 
>    XFree86 already contains a better way to do it and the applet 
>    is just hosed.
 
If the keymap is part of GNOME, I can't see the reason for including it
in X. Doesn't the xkb keymaps that already exist in X fit your current
bill anyway ?

>  - I would like to see a remote desktop feature work "out of the box,"
>    Alan I mailed you about this a while back, here is a mail that
>    includes the notes I made on that:
>    http://mail.gnome.org/archives/desktop-devel-list/2002-December/msg00221.html
> 
>    I realize xf4vnc exists, but something folded into XFree86 upstream
>    would be a plus. libvncserver or functional equivalent would also
>    be nice to have, if not as part of X, at least readily available.
>    Ideally if the server side is a VNC server it would use the same
>    libvncserver as any client side VNC server, so that features can be
>    added in one spot.
 
GPL code won't make it into XFree86 at all. That's why xf4vnc exists. 
There are extra things you can do when your inside the Xserver that I
currently haven't put too much thought into if the interface lived on
the client side. I have suspicions that performance wouldn't be nearly
as good, due to events being generated on every damaged region update.

>    Ideas on how this should be done such that it would be acceptable
>    for upstream integration would be very useful. I have working on
>    this somewhere on my back burner; far enough back that it won't
>    happen all that soon, but near enough that it could happen
>    someday. ;-) In the meantime various random people have expressed
>    interest in doing it and I'd like to have a plan of action
>    available that they can just follow if they get excited one
>    weekend.
> 
>    Some people have suggested that this be done with X protocol 
>    extensions rather than using VNC, but to me that's probably 
>    more effort than the problem justifies.
 
It may well be possible with the X protocol. It's something I'm currently
interested in, but lack of time, I've haven't devoted much to it.

>  - Double buffering that spans multiple windows, specifically the
>    window manager frame and the application inside it. Some mechanism
>    for WM and app to coordinate when to pop the buffer and draw to the
>    screen.
> 
>    Within a single X window, a server-side damage region and backing
>    store extension might be interesting if it were more efficient - we
>    currently do this on the client side for GTK+, but could use a
>    server side feature when available if it offered advantages.
> 
>    The multi-window case is the one that can't be done client side
>    right now, though.

I'm not too sure what your getting at here, can you elaborate a bit more ?
There is the double buffer extension (which I haven't looked closely at)
which maybe we can utilize. I know the hardware drivers don't interface
into this extension at all yet. 

>  - Another thing that might partially address the same issue 
>    as double buffering would be a way to sync to the monitor 
>    refresh, has been discussed in the past I know

I think the SYNC extension can help here, again none of the hardware
drivers make use of it yet. Both the doublebuffer and sync extensions
are something that should be added for XFree86 5.0.

>  - Earlier on this list we had a thread about how it was hard to do
>    smooth animation. I can't find the link now, but some general
>    thinking in that area would be useful.
 
More information would be useful.

>  - Some of the freedesktop.org specs such as EWMH could use broader
>    review and feedback.
 
Post a link so I know I'm looking at the right thing.

>  - I think it would help people test and work with the XFree86
>    codebase if you could basically just run a build-and-install script
>    which would leave you with a way to start an X session using
>    XFree86 from CVS, without messing up the files owned by your
>    packaging system. i.e. type one command, walk away, shut down
>    current X, start the new one, now you're using your custom X build.
>    Maybe it's this easy now, but it isn't clear to me how you do it.
>    When I wrote that DAMAGE extension I debugged the whole thing with
>    Xnest instead of the XFree86 server.

'make World' and then 'make DESTDIR=/yourpath install' is all you need to do. 

This shouldn't mess up anything and will install everything from the build
into '/yourpath'. Create a new XF86Config file to use this new path, and
off you go.

Alan.