Xserver, Remote Access

Xserver basics:

- DAMAGE, XFIXES, XevIE, COMPOSITE, XKB, XCURSOR, XInput

Bill Proposal: take DAMAGE and XFIXES wholesale into the spec.

- Keith: suggests that as XFIXES will grow, we only want to take a specific version of it; DAMAGE certainly can be taken wholesale

- Keith suggests XFIXES version 2.0. Future plans for it aren't specifically for accessibility – it's more of a catch-all location for misc. fixes & extensions. Most existing things are focused on accessibility (save selection content tracking [could be useful for accessibility])

XFIXES contains: cursor tracking, semantic assocation of the cursor meaning (a string associated with each cursor – needs XCURSOR extension for setting this), fundamental region primitives (used by DAMAGE), and obtaining the cursor image.

Look to take a portion of XKB (already discussed earlier)

XCURSOR not ready for standardization

XEvIE (now being driven by Sun LookingGlass folks) – started out life as a place to intercept/interdict keystrokes (after “cooked” by AccessX); also being extended for mouse interception (needed for mapping the physical view of the mouse on the physical view of the desktop to a 3d desktop).

COMPOSITE: “small” extension that has ~5 calls. Direct windows to off-screen pixmaps (on video memory), and then redisplay them. Status: version 0.something, but it is in Xorg 6.8.0 and later. [Peter: we have no AT using COMPOSITE yet, suggests we wait to try to standardize on it until we have AT using it]. COMPOSITE is a relatively new extension, and nothing like it has really been implemented before.

Xinput: the spec. is fairly OK; the implementation sucks. Persistant naming of USB-based stuff is broken for HID (e.g. Mice, switches). Bill: Xinput spec. is broken for mice – the name shall be “Mouse”. Implementations don't follow this spec. - does “Mouse[x]”. Keith: expect to rev. the Xinput spec., in months (not years).

Action item: collect the set of USB vendor info for all switches, head trackers.

X extension Summary:

Take DAMAGE into FSG spec., take XFIXES as it is now into FSG spec.

XKB already discussed.

XEvIE needs to be sorted out

XCURSOR “broken”, need to wait

COMPOSITE too new, need AT using it before we move forward

Other XServer issues

2d apps vs. 3d apps, shading, etc.

[Peter: we should look to Universities (NSF or other grants) to see what these new features do for people with visual impairments]

Input devices – e.g. ASR into X

Other issues: image filtering to the RENDER extension? Anything we can do with legacy applications to change their color mapping. NOTE: RENDER extension changes how we do color mapping, and we have lots of anti-aliased stuff. So this has some implications for color mapping.

Font stuff? All out of the X server, done in the client. Nice thing: pretty much all fonts now are scalable (see freetype).

Remote Access issues:

su ... xhost ...

Use case: running a remote session (e.g. LTSP Linux Terminal Server Project – but now things aren't all on the remote CPU [browser may run locally, window manager too]; remote desktop login; ssh + xhost). Both bonobo & DBUS discovery & lookup are tied to user:host. Ideally this would be tied instead to DISPLAY. Jonathan: DBUS' main scope is per session (not tied to home directory or machine) but current implementation is per-machine . The goal of DBUS is to “define the session”. Bill: the notion that DISPLAY=session is not future proof (from comments from Keith Packard and research he is involved with). Significant convention details here to make this work with DBUS.

Note: our current approch for FSG 1.0 will be silent on activation & discovery; perhaps we will know enough with DBUS to move to a DBUS-based activation & discovery mechanism in time for a 1.0 spec. The sole problem is activation/discovery; CORBA can certainly talk to remote devices.

Harald: what happened to ICE? Keith: there are numerous authentication, discovery & security issues.

Keith: for remote access, never recommend running X raw – always use ssh. So, do we want to standardize on ssh port forwarding (for X, DBUS, audio, etc.). Peter: leary of formally requiring this, perfer a “best practices”.

remote audio, ASR

Keith: there are a lot of network audio servers in the world, most suffer from problems. There are several new audio servers. We need to look at APIs to talk to: Jack & libALSA. Jack is a way to connect multiple servers together, but not intrinsically a network service. ALSA will automatically do mixing. So if things move to libALSA, we can then use that as our bottleneck and fix that. Marc: ALSA doens't work everywhere. Keith: also look at Jack (which sits on top of ALSA). MAS – yet another audio API that nobody supports (so dead in the water from that point of view). Bill: what about the legacy issue - /dev/audio, or esd. Keith: both esd and ARTS can run on libALSA. There is a libALSA front end to Jack (which then sits on top of the “real” libALSA for the system). Jack requires floating point, and libALSA doesn't run on ARM.

Keith's summary: a wide variety of mediocre choices here.

Samuel: we also need to forward Braille streams too - where is the Braille display? [Note: BtlTTY does support USB Braille displays. BrlAPI is networkable (but we need to do discovery and activation)].

Persons mentioned in this document are: Peter Korn, Bill Haneman, Keith Packard