[Deron.Johnson at Sun.COM: Proposal for X Server Plug-in Picker]

Daniel Stone daniel at fooishbar.org
Thu Nov 30 11:13:14 PST 2006


xorg-arch is essentially dead, so, bouncing.

Cheers,
Daniel

----- Forwarded message from Deron Johnson <Deron.Johnson at Sun.COM> -----

Date: Thu, 30 Nov 2006 11:11:20 -0800
From: Deron Johnson <Deron.Johnson at Sun.COM>
To: keithp at keithp.com
Message-id: <456F2CD8.4090806 at sun.com>
Cc: xorg-arch at lists.x.org
Subject: Proposal for X Server Plug-in Picker
List-Id: "X.Org Architecture Working Group Discussion List"
	<xorg-arch.lists.x.org>


Hi Keith,

Here is a design proposal that stemmed from conversation at the Ubuntu 
conference about the server plug-in picker.
This is a design which I hope will meet both our needs. It should allow 
you to implement your latest thinking on
input redirection while at the same time allow me to implement an 
approach which is performant for LG.
Please let me know if I am on the right track. I realize the many of the 
details may neeed to change but I need to know if
you approve of the general approach before I spend a lot of time 
implementing it.

And, if you are too busy right now to review this, I would appreciate it 
if you could give me
an estimate for when you might have the time. Thanks.

   -Deron

--------------------------------------------------------------------------------------------------------------

Xorg Xserver Plug-in Picker Design
Deron Johnson
deron.johnson at sun.com
Version 0.1 (DRAFT)
Thu Nov 30 10:38:21 PST 2006


Introduction
------------

This document describes the design of the Xorg X server Plug-in
Picker. The purpose of the Plug-in Picker is to allow desktop
environments to extend the X server window picking semantics. In the X
server, "window picking" is the process of taking a point in screen
coordinates and determining in which window the point lies. The normal
X server picking process is to hierarchically search the window tree
to find the lowest child window in which the point lies. There are
several ways in which a desktop environment might wish to extend this
behavior. For example, a 3D desktop environment such as Project
Looking Glass might use the screen position to perform a pick into a
3D scene graph.

The Plug-in Picker interface is an X server internal interface. The X
server code which is involved in window picking is replaced with calls
through an interface to a Picker module. Different pickers with
different semantics can be implemented. Desktop environments can
install and activate a picker that is specific to their needs.  They
use the Picker extension to do this. The Picker extension allows a
desktop manager to select a particular Picker module to implement
picking for a particular window hierarchy.

This design supports different pickers for different windows and
screens. For example, the windows on one screen could use normal X
server picking and the windows on other screen could use Looking Glass
picking.

In addition to interacting with the Picker extension, a plug-in Picker
module is allowed to interact with other server extensions to
accomplish its task.  Picker-specific extensions can be defined to
allow clients to provide information to help the Picker do its job.

In addition, a Picker module can provide its own internal protocols to
allow clients to provide information.  For example, a Picker could
implement a private "back-door" socket protocol to delegate picking to
an external process with out going through an X client connection.

Pickers are allowed to block the X server but, of course, the amount
of time the server is blocked should be minimized.


Picker Interfaces
-----------------

A. Interface from X Server to Picker Module

This section defines the interface that a Picker provides to the rest
of X server.  The interface is defined as a set of macros. These
macros invoke routines through a function vector.

PICKER_XY_TO_WINDOW (Window Ptr pWinScr, int x, int y)

   Given a screen (specified by a window on that screen) and absolute
   screen point (x, y) this routine calculates the lowest level subwindow
   in which the point lies.

PICKER_FIXUP_EVENT_FROM_WINDOW (WindowPtr pWinScr, xEvent *xE,
                               WindowPtr pWin, Window child,
                               Bool calcChild)

   Modifies the fields of the given event to be appropriate for the given
   destination window pWin.

PICKER_QUERY_POINTER (WindowPtr pWinScr, INT16 inX, INT16 inY,
                     INT16 *pOutX, INT16 *pOutY, Window *pOutChild,
                     Bool *pOutSameScreen)

   Implements the XQueryPointer calculation for root window of the screen
   of the given window.

PICKER_TRANSLATE_COORDS (Window pWin, Window pDst, INT16 inX, INT16 inY,
                        INT16 *pOutX, INT16 *pOutY, Window *pOutChild,
                        Bool *pOutSameScreen)

   Implements the XTranslateCoords calculation for root window of the
   screen of the given destination window.

PICKER_WINDOWS_RESTRUCTURED ()

   Used by the X server to tell the picker that the window tree has
   changed.

B. Interface from Picker Module to X Server

A Picker is allowed to reference X server external global variables.

C. xEvent Reserved Fields

The following fields in the xEvent.keyButtonPointer structure are 
reserved for
use by the Picker from the time the event is first created to after
PICKER_FIXUP_EVENT_FROM_WINDOW is called:

   event
   child
   eventX
   eventY

The Picker, and any extensions it cooperates with, may store information in
these fields. (A picker will use do this in order to optimize its picking.
For example, a picker might use a "pick-ahead" extension to perform early
picking and store the results in these fields).

The server must not use or modify these event fields until after calling
PICKER_FIXUP_EVENT_FROM_WINDOW.

   [Design Note: this pick-ahead information is crucial for good Looking
   Glass performance. For smooth interactivity LG needs to be able to
   process multiple events per rendering frame. Because the unaided
   Picker extension will only fire off occasional picking requests to
   the LG Display Server (DS), and not stream them, it is not going to
   perform well. But if we stream input events to the LG DS and
   use this as pick-ahead information, and if we toss this pick-ahead
   information when the window tree changes and use the asynchronous
   picking protocol instead, we combine the best of both worlds: we
   have the performance of streaming and the ability to handle changes.]
  
D. Picker Extension Interface

The Plug-in Picker interface provides an X extension which is used to 
activate
and control plug-in pickers. This extension is called Picker. It 
provides the
following requests:

typedef XID Picker;

Picker
XPickerAcquirePicker (char *pickerName, int clientMajor, int clientMinor,
                    int *serverMajor, int serverMinor, int nWords,
                    int *pickerControlInfo)

   If the named picker has not already been loaded into the X server
   the specified picker shared object library is dynamically loaded
   and associated with the XID which is returned. The reference count
   of the picker is initialized to 1.

   If the named picker has already been loaded into the X server its
   reference count is merely incremented.

XPickerReleasePicker (Picker picker)

   Decrements the reference count of the given picker. When the reference
   count reaches 0 any memory associated with the picker can be reclaimed.
   by the X server.

int
XPickerBindPicker (Window win, Picker picker)

   Associates the given picker with the given window. This picker will
   be used for picking on this window and its descendents.

   Note that unless the the pickers of all ancestor windows support
   multi-level picking this picker may be ignored. (See the "Multi-Level
   Picking section).

int
XPickerUnbindPicker (Window win)

   Disassociates the given window's picker from the window.
   The window's picker is set to the default picker.

XID
XPickerQueryPicker (Window win)

   Returns the XID of the picker associated with the given window.
   If the default picker is bound INVALID is returned.

E. Where do the Picker Modules Come From?

Picker modules are installed on a machine in a TBD directory.
Each is a shared object library (.so). The file names have the format
<pickername>.so.<majorVersion>.<minorVersion>


Multi-Level Picking
-------------------

Pickers are allowed to use other pickers to perform picking on
subwindows.  Pickers which support this are said to support
"multi-level picking."  Pickers are allowed to support multi-level
picking but are not required to do so.

A multi-level picker will use the picker associated with a specific
window when it reaches that window in its picking search. For example,
lets say that the root window is set to use Picker A for its picking.
If Picker A determines that the point is somewhere in subwindow B it
calls the Picker B, which is the picker of subwindow B. Picker B then
continues the search from subwindow B on downward. Along the way, if
Picker B supports multi-level, it may call other pickers.

Multi-level picking allows desktop environments to be embedded in
other desktop environments. For example, imagine Croquet embedded in a
window within Looking Glass.

However, because multi-level picking is complex to implement it is not
required that all pickers support multi-level picking.  It is at the
discretion of the implementor of the desktop environment.


Server Dix Implementation
-------------------------

This section describes the changes that must be made to the X server
dix code in order to implement the Plug-in Picker interface.

In events.c:

   ComputeFreezes is modified to call PICKER_WINDOWS_RESTRUCTURED before
   calling XYToWindow.

   FixupEventFromWindow is modified to only call
   PICKER_FIXUP_EVENT_FROM_WINDOW.

   XYToWindow is modified to only call PICKER_XY_TO_WINDOW.

   CheckMotion is modified to call PICKER_WINDOWS_RESTRUCTURED for the
   xE == NULL case.

   ProcQueryPointer is modified to call PICKER_QUERY_POINTER to do its
   work.

In dispatch.c:

   ProcTranslateCoords is modified to call PICKER_TRANSLATE_COORDS to do
   its work.


_______________________________________________
xorg-arch mailing list
xorg-arch at lists.x.org
http://lists.x.org/mailman/listinfo/xorg-arch

----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20061130/378dcd59/attachment.pgp>


More information about the xorg mailing list