[linuxkernelnewbies] X.Org Wiki - XDC2007Notes

[Peter Teoh]

http://www.x.org/wiki/XDC2007Notes#head-6a32160debfaa441605bee568704bea44bae18b6 Peter Hutterer: MPX Slides: PDF slides] Basic problem: Only one focus for keyboard and mouse input All the existing multi-user toolkits don't work. You have to write to them, doesn't work for arbitrary apps. So, hey, let's give X multiple pointers! Basically all functionality works. Each pointer acts like a core pointer, like an XI pointer, can have different shapes, can be queried, can be warped, each keyboard can have different focus, and pointers and keyboards can be dynamically associated. So what changed? Event delivery is modified so that every device has its own sprite structure, instead of just one like we have now. Therefore, on event dequeue, we know _which_ device generated the event. Cursor rendering goes entirely through software now, since basically no hardware has more than one cursor in hardware. This had to be extended to handle the cases where the backing tiles for each cursor overlap. In standard X, you get one shape per window, and shapes can be inherited. In MPX, each device can have one shape per window, and the inheritance works the way you expect. QueryDevicePointer WarpDevicePointer DefineDeviceCursor ChangePointerKeyboardPairing Device{Enter,Leave}Notify PairingChangedNotify ~30 calls in the core protocol no longer have a defined state. Possible solution: "SetPointerBehaviour" for FollowSingle, DevicePointer, etc., which the window manager would enforce for naive apps. Lots of race conditions until this happens when multiple users are interacting with the same window or widget. Really need window manager support for this to work. There is a demo wm that works, blackbox kinda works, metacity completely doesn't. Also, applications need to become aware of this too. Pointers can pop in and out of existance now. Things to think of: Floor control Relative device events Multi-user cut-and-paste Mouse cursor restacking Gesture events It's not ready yet. Questions: Composite and DMX integration? "Not yet, would be cool" Use cases? "Lots, needs more research" How to handle hotplug? "That's Daniel's problem." (Intermission for lunch orders) Philip Langdale: Virtual Multihead in VMware Host support Single head: plain fullscreen Multihead: Old school manual window resizing Guest support, since this was pre-RANDR 1.2: yet another pseudo-xinerama. Additional call to the vmware extension to send a new xinerama config. Needs RANDR 1.2 integration. EWMH needs extending to cover maximization across multiple screens. (shiny demo) (another intermission) Keith Packard: RANDR 1.2 Things we had tried before: Xinerama, xf86vidmode, RandR Classic Core X does not support multiple screens well. Number of screens is fixed, size of each screen is fixed, monitors probed at startup. This info is passed over to Xlib at app startup, and is really hard to fix. The server also makes this fragile internally, but that's fixable. But many resources are per-screen, so it just doesn't work the way you want. Xinerama. Merges many monitors into one screen. Allows apps to move across screens, which is cool! Screen config was fixed at startup, so suitable for fixed multi-head environment. (Initial implementation also happened to be wildly inefficient.) Changing modes was xf86vidmode. Changes monitor mode on the fly, but not the screen size. Whee, pan and scan. Also exposes gamma correction. But screen size is still fixed at startup, and set of modes fixed at startup. Changing screen size was RandR. Runtime changes to screen size, but still fixed set of sizes and monitor modes, and mode expressed as size and refresh only. Randr 1.0 done for kdrive for rotation. When added to xfree86, was done without changing drivers, so no mode reprobing, no rotation... RandR 1.2 fully expresses hardware capabilities. All configuration can be changed. Unified config file structure, reduced driver-specific code, unifies the semantics of the above extensions. The three objects: Screen, CRTC, Output. (Pretty picture). One screen, N CRTCs, connected to M outputs. (Shiny demo) What else can it do? LUT for gamma adjustment. Arbitrary output properties. User defined modes. New driver-independent API. Minor driver problems. XAA is kind of gross, DRI is fixed. Protocol is finished, DIX implementation is finished, intel driver working, radeon and nouveau nearly working, gtk-based UI demo. Need to fix remaining drivers and finish rotation/reflection work.