Re: Device Properties Protocol Spec - Draft 1

[Peter Hutterer]

On Sun, Sep 07, 2008 at 04:13:18PM +0200, Tomas Carnecky wrote:
> Peter Hutterer wrote:
> > On Sat, Sep 06, 2008 at 05:15:51PM -0700, Keith Packard wrote:
> >> On Sat, 2008-09-06 at 17:23 +0300, Daniel Stone wrote:
> >>
> >>> Isn't this just PropModeReplace with nItems = 0?
> >> Is there a difference between a property of length zero and an absent
> >> property?
> > 
> > nItems = 0 remove the content, but not the property itself, hence the need 
> > for
> > DeleteProperty. This is also the behaviour core has with window properties.
> 
> What is the difference between a property with no content and no
> property? In which situations would this distinction be useful?

An empty property indicates that e.g. the driver knows about this property,
but no data is available (or can be exported).

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[RFC] Preliminary XI 2 feature list

[Peter Hutterer]

Following XDS, various notes, the discussions and preliminary executive
decisions by me, here's a first draft of XI2 features. If you have anything to
add, please speak up.

Time-line: I'd like to get it into server 1.6 but it doesn't look particularly
likely. 7.5 is more likely.

- Compatibility with XI 1.x, although some requests will be deactivated or of
  limited functionality.
- 16 bit device IDs
- All events available as XGE events.
- Event selection through event masks (instead or in addition to the event
  classes).  i.e.  the common cases of "select from all devices" and "select
  from all master devices" will be simplified.
- Devices may have relative + absolute axes simultaneously, and change the
  mode on any of these axes at runtime.
- Relative coordinates as a separate event.
- 32 bit keycodes (reliant on XKB2)
- ListInputDevices will include the currently attached Slave
- Axis and button labelling through device properties.
- subpixel resolution (from relative devices) available to clients.
  i.e. you get the data in screen coordinates, but with subpixel resolution
  available as fixed floating point.
- no window access protocol, this will be thrown out.
- dynamic device classes - device may add/remove classes at runtime.
- aspect-ratio scaling of valuators.

Probable implementation details:
- libXi: "namespacing": i.e. X will be XI
- server-internal use of XGE events, XI 1.x events emulated when needed.
- some standardisation on axis label Atom names.
- Clients have to announce XI2 support, otherwise they will be treated as XI
  1.x clients. 

Once the feature discussion is complete, I'll get a protocol spec out.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XTest and multiple pointers

[Peter Hutterer]

On Tue, Sep 09, 2008 at 11:24:48AM +0200, Florian Echtler wrote:
> we're currently trying to control multiple X pointers through XTest.
> Moving them using XTestFakeDeviceMotionEvent works as expected; however,
> sending a button event using XTestFakeDeviceButtonEvent doesn't.
> 
> In fact, the test program from [1] segfaults in XNextEvent
> (xorg/lib/libX11/src/NextEvent.c, line 51). qelt (and therefore
> dpy->head) doesn't point anywhere sensible, so is this perhaps an
> internal bug?

This is usually caused by the event being passed in not being the right size.
Xlib is picky about the size of events, so you must make sure you always pass
in an XEvent struct (96 bytes), even if what you actually use is a
XDeviceMotionEvent (or whatever).

Could this be the cause of your issue?

I can only test this on my other box next week, not before then.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Device Properties Protocol Spec - Draft 1

[Peter Hutterer]

On Mon, Sep 08, 2008 at 11:19:21AM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
>> The difference to the current implementation is that there is no
>> meta-information about the property. This information included immutable,
>> client-created, range and pending. I deem all four as too much information.
>>
>> If such information is required in the future, such requests can be added
>> easily in future versions of XInput.
> I guess you are just not exposing those?
> My concern is that a client could remove properties installed by the  
> server or a driver.
>
> In the readonly case, I think it should be possible to tell a property  
> which refuses to be set due to the value apart from a property which  
> generally is 'read-only', i.e. has a always-fail setter or some  
> unexposed flag. Could be BadValue vs. BadMatch, but I'm missing it in  
> the ChangeDeviceProperty spec (readonly is arguably a type mismatch).

we could do that as BadAccess, though I'm not sure how that'd mingle with the
security stuff.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: a question about upgrading system for MPX

[Peter Hutterer]

On Wed, Sep 10, 2008 at 10:10:09AM +, Wayne wrote:
> If I want my system to have MPX, can I just upgrade my system
> from xorg-server-1.5.0.tar.gz, or I still have to upgrade from
> git version?

mpx won't be in a released version until server 1.6 or possibly 1.7.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-synaptics:master: 1 commit(s)

[Peter Hutterer]

On Wed, Sep 10, 2008 at 04:57:57PM +0200, Sascha Hlusiak wrote:
> Hi Peter,
> 
> > Commit against master at e622b00f...:
> > commit c57a7b463fb86d065fc6fe316ed25f302d51e5c6
> > Author: Peter Hutterer <[EMAIL PROTECTED]>
> > Date:   Wed Sep 10 23:37:27 2008 +0930
> > 
> > Claim that we are a XI_TOUCHPAD, not a mouse.
> > 
> > If this still breaks with KDE, fix KDE or the server.
> Say, what is this type_name for? In what client program is it used, how
> did it break KDE?

>From the XI protocol specs:
---
The type field is of type Atom and indicates the nature of the device.
Clients may determine device types by invoking the XInternAtom request passing
one of the names defined in the header file XI.h. The following names have
been defined to date:

MOUSE TABLET KEYBOARD TOUCHSCREEN TOUCHPAD BUTTONBOX BARCODE KNOB_BOX TRACKBALL 
QUADRATURE SPACEBALL DATAGLOVE EYETRACKER CURSORKEYS FOOTMOUSE ID_MODULE
ONE_KNOB NINE_KNOB
---

So type is simply a "standardised" identifier. I'm not sure how popular e.g.
"barcode" or "nine_knob" are, but differing between mouse, touchpad,
touchscreen, etc. is quite useful.

This change was triggered by Red Hat Bug 324721 [1], where we need
gnome-mouse-properties to differ between mice and touchpads. This is the
mechanism in place for it.

Regarding the KDE reference, the diff says:
-local->type_name   = XI_MOUSE; /* XI_TOUCHPAD and KDE killed 
the X Server at startup ? */
+local->type_name   = XI_TOUCHPAD;

How exactly this was a problem I don't know, but we should fix the bug in KDE
or the server (whichever appropriate) rather than work around it in the
driver.

Cheers,
  Peter

[1] https://bugzilla.redhat.com/show_bug.cgi?id=324721
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-synaptics:master: 1 commit(s)

[Peter Hutterer]

On Wed, Sep 10, 2008 at 05:55:58PM +0200, Sascha Hlusiak wrote:
> I'm asking because of the joystick driver that I maintain and that at
> the moment claims to be XI_MOUSE as well. Should I rather change it to
> "JOYSTICK", define a new atom for that or make it even configurable? I
> still don't know about the impact but I think it might be that some
> applications might refuse to work with devices they don't know about
> (gimp?).

Gimp with a joystick is probably not something for the light-hearted :)

I'd say XI_MOUSE is wrong. JOYSTICK would be good, alternatively you could
also think about having JOYSTICK, GAMEPAD, and whatnot, although as the XI_XYZ
atoms show too many aren't that great either.

Applications that expect XI_MOUSE from a joystick and break can be fixed with
few LOC.

It does leaves the question - should we merge JOYSTICK (etc.) into XI.h as
defaults, or do you think it is better to provide them as part of the joystick
driver?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [RFC] Preliminary XI 2 feature list

[Peter Hutterer]

On Thu, Sep 11, 2008 at 09:29:45AM +0200, Roderick Colenbrander wrote:
> I'm still not clear which one will provide the exact events from the device?
> Relative events doesn't mean the device events. If this is pointer events,
> then it won't help. Pointer gets stuck on the border of the screen. But not
> mouse/trackball.

This is the reason why relative events will be separate from standard events
as they won't be affected by clipping. 

> Also it would be nice to have a way to completely stop pointer from moving.
> Right now it's impossible, even with Xevie which was supposed to add exactly
> that.

Grabbing an attached SD temporarily detaches it from the MD. Alternatively,
you could explicitly detach it. Either way, the visible representation of the
cursor ceases to move (from this device anyway, other attached ones may still
change the cursor position).

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xf86-input-synaptics:master: 1 commit(s)

[Peter Hutterer]

On Thu, Sep 11, 2008 at 08:44:01PM +0200, Sascha Hlusiak wrote:
> > I'd say XI_MOUSE is wrong. JOYSTICK would be good, alternatively you could
> > also think about having JOYSTICK, GAMEPAD, and whatnot, although as the 
> > XI_XYZ
> > atoms show too many aren't that great either.
> Isn't it more important for applications to know what _driver_ provides
> the device, so they know about capabilities and things to set? The
> _nature_ of the device seems only to be useful for displaying an image
> of what the device might look like. Even if mouse, kbd and evdev provide
> similar devices there might be a difference for the application. How are
> combo-devices (tablet with keys through evdev) recognized and exposed to
> applications? Isn't it dangerous for drivers other than evdev/mouse to
> export XI_MOUSE, even if it is a mouse?

My understanding of the spec is that it is merely a hint what the device is.
As you say, this may only be useful for a few things but I don't believe that
it should serve to expose which driver is running.

In theory, any device-specific modifications should respone with appropriate
error codes if the modification cannot be performed. Think of DeviceControls,
they both provide appropriate errors if you're trying to change on that isn't
there. Furthermore, there are quite a few settings that are provided by
multiple drivers anyway.
 
> > It does leaves the question - should we merge JOYSTICK (etc.) into XI.h as
> > defaults, or do you think it is better to provide them as part of the 
> > joystick
> > driver?
> For consistency and ease, I'm for merging it to XI.h.
> 
> But I don't think it makes much sense, if it is a per-driver setting.
> Leave it to the drivers then, that makes adding new types easier.

I tend to lean towards the XI.h approach, simple because it keeps the numbers
of different device types low. And there's the classic
monkey-banana-experiment reasoning: "because we've always done it like that"
:)

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: synaptics: touchpad with 1 buton, emulate middle and right click

[Peter Hutterer]

On Tue, Sep 16, 2008 at 11:20:01PM +0200, Mildred Ki'Lya wrote:
> I have a macbook, and a while ago (May 2008, when synaptics wasn't
> included in the Xorg project), I made a patch in order to improve
> usability of touchpad with one mouse button only.

Thanks! The patch had been applied as c32b4d47b94c2c18fab7f30588ddae8827e38f27
in the xf86-input-synaptics repository and is already part of the 0.15.0
release.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: events in evdev.c

[Peter Hutterer]

On Wed, Sep 17, 2008 at 08:38:09PM -0400, Chuck Robey wrote:
> I don't know if this is important or not, and I won't harp on this, but I've
> heard before that an attempt is made both to keep evdev.c very current, AND to
> have it not have anything in it that is Linux-only.  

AFAIK, only the linux kernel has the evdev interface that the X.org evdev
driver uses, so the linux-depency is not accidental.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Raw mouse input is distorted

[Peter Hutterer]

On Wed, Sep 17, 2008 at 06:46:17AM -0700, Hauberg wrote:
>   Now, my problem is that X seems to somehow accelerate the output from the
> 'usbtouchscreen' module, so that when I move my finger to the left, the
> cursor moves about twice as far to the left as my finger did. This does not
> correspond to the output from the 'usbtouchscreen' module. So, I'm a bit
> confused here: does X place the cursor at the position outputted by the
> kernel, or does it do some fancy things?

after a quick 30s peek into the evtouch driver:
it always inits x/y with a range of [0-1024]. you'd need to change this (in
EVTouchPreInit) to reflect the real range of the coordinates you post from the
driver module.

all events are posted as absolute from the evtouch driver
(xf86PostMotionEvent, xf86PostButtonEvent), which means they will get scaled
by the server into the screen space, i.e. if the screen has a resolution is
2048, this means that the device coordinate 512 will map to the screen
coordinate 1024.

This could be the reason for your scaling issue. Setting up the axes with the
right values should fix that. alternatively, you could make sure the kernel
driver pre-scales to a range of 0-1024.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Raw mouse input is distorted

[Peter Hutterer]

On Wed, Sep 17, 2008 at 09:26:08PM +0200, Simon Thum wrote:
> Maybe evdev works better? I seems there is a problem when both absolute 
> AND relative axes are exposed,  

The reason for this is that there's a couple of popular devices
(keyboard/mouse combos) that claim to have both relative x/y axes and absolute
x/y axes simultaneously.

You lose the ability to go past the min/max reported for x/y (which in my case
was 255/255). It can be fixed in the driver, but nobody volunteered for it
yet.

If you feel like it: https://bugs.freedesktop.org/show_bug.cgi?id=17637

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xserver from git: libXi dependency

[Peter Hutterer]

On Fri, Sep 19, 2008 at 04:28:20AM +0700, Mikhail Gusarov wrote:
> Xi/chdevhier.h includes  which is in libXi, but
> xserver configure script does not check for the libXi. Is it a bug?

Thanks, that's a bug. Fix pushed as cc20112a65d3f641ce0261c86a541f94fae5215c.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-evdev 2.0.5

[Peter Hutterer]

Just one fix - some kernels invalidate the device late after resume, leaving
us with dead devices. This issue is addressed by reopening the device if a
read error occurs.


Peter Hutterer (2):
  Attempt to re-open devices on read errors.
  evdev 2.0.5

git tag: xf86-input-evdev-2.0.5

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.5.tar.bz2
MD5: aabf047629d279b0eb4cd236b9de3121  xf86-input-evdev-2.0.5.tar.bz2
SHA1: 9b6b77e6d9aa9bfbe0b7a31d4d070c0f6d372311  xf86-input-evdev-2.0.5.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.5.tar.gz
MD5: cdca14fa2fd7daffcb3c8d459e480b4c  xf86-input-evdev-2.0.5.tar.gz
SHA1: 801bb0c74803e61d65868fe61198840a2e1aa465  xf86-input-evdev-2.0.5.tar.gz


signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Building X

[Peter Hutterer]

On Fri, Sep 19, 2008 at 01:46:21PM +1000, Russell Shaw wrote:
> I built X from git. I get a stippled background when X starts but the
> mouse cursor is invisible. The mouse is working because i tested it
> with xev. I built and installed in this order:

commit e02f864fdf19a5ab1682336be343c57fdb69ef43
Author: Adam Jackson <[EMAIL PROTECTED]>
Date:   Wed Aug 20 13:24:03 2008 -0400

Suppress cursor display until the first XDefineCursor() request.

Yes, this means the server will start without showing a cursor.  Pretty
much any application that wants to interact with the mouse will define
cursors, so this essentially just delays showing it until gdm (or
whatever) loads.


Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [xorg-server-1.5.0] keyb hang after starting q3

[Peter Hutterer]

On Thu, Sep 18, 2008 at 11:51:47PM -0500, Tobias Jakobi wrote:
> After ioquake3 is started all keyb and mouse input stop. You can't move  
> the cursor, you can't click. Switching to another application isn't  
> possible, even switching to the VTs isn't possible.
> All input is simply dead.
> [...]
> I consider this a serious bug with the X input.

> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> [mi] mieqEnequeue: out-of-order valuator event; dropping.
> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> [mi] mieqEnequeue: out-of-order valuator event; dropping.
> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
> [mi] mieqEnequeue: out-of-order valuator event; dropping.

I think your server is probably stuck in an infinite loop :)
Input is still coming in, but not being processed because something else is
hogging the server. 

> (EE) intel(0): underrun on pipe B!

I blame the graphics driver.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: events in evdev.c

[Peter Hutterer]

On Sat, Sep 20, 2008 at 11:48:08AM -0400, Chuck Robey wrote:
> I myself really like the approach that xf86-input-joystick takes, it allows 
> the
> approach that evdev takes for Linux, but it doesn't try to suppose that the
> event interface that only works for Linux can work for other OSes.  You know 
> how
> evdev is usually put forward as the best example of driver writing?  I think
> that the joystick is a way better (more portable) example.  Other OSes *do* 
> have
> events, but they're intra-kernel only, not exported to apps.  And, FreeBSD
> doesn't have wscons (although I like that idea, myself).

evdev is put forward as standard example because - unlike most other drivers -
most of its code deals with being an X driver, not a hardware driver.  There's
little protocol crazyness, only few ifdefs, and the code is relatively
straightforward.

I'm sorry if you don't see how that is a good way of _learning_ how to write
an input driver. 

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Potential issue with xorg-x11-drv-evdev ( 2.0.4-1 on fedora 9)

[Peter Hutterer]

On Sat, Sep 20, 2008 at 03:44:20PM -0700, Nikolay Karasev wrote:
> My yesterday's update of Fedora 9 installed these updates
> xorg-x11-drv-evdev version 2.0.4-1
> xorg-x11-server-Xorg 1.5.0-1
> xorg-x11-server-common 1.5.0-1

https://bugzilla.redhat.com/show_bug.cgi?id=456936#c19
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] xkb: fix core keyboard map generation. #14373

[Peter Hutterer]

According to Section 12.4 of the XKB Protocol Spec, if a key only has a single
group but the keyboard has multiple groups defined, the core description of
the key is a duplication of the single group across all symbols. i.e.
G1L1 G1L2 G1L1 G1L2 G1L3 G1L4 G1L3 G1L4

The previous code generated G1L1 G1L2 G1L3 G1L4 G1L3 G1L4, leading to
"invented" groups when the process is reversed.

Note that this creates wrong key types on reconstruction from core to xkb,
i.e. any single-group key with a key type that is not one of the canonical
four (Sec 12.2.3), will get the assigned type on group 1, and a canonical type
for the other gruops.

X.Org Bug 14373 
---
 xkb/xkbUtils.c |   39 ++-
 1 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/xkb/xkbUtils.c b/xkb/xkbUtils.c
index 8339cef..b5c0ac2 100644
--- a/xkb/xkbUtils.c
+++ b/xkb/xkbUtils.c
@@ -486,6 +486,40 @@ CARD8  keysPerMod[XkbNumModifiers];
if (groupWidth>2)
nOut= groupWidth;
}
+
+   /* See XKB Protocol Sec, Section 12.4.
+  A 1-group key with ABCDE on a 2 group keyboard must be
+  duplicated across all groups as ABABCDECDE.
+*/
+   if (nGroups == 1)
+   {
+   int idx;
+
+   groupWidth = XkbKeyGroupWidth(xkb, key, XkbGroup1Index);
+
+   /* AB..CDE... -> ABABCDE... */
+   if (groupWidth > 0 && maxSymsPerKey >= 3)
+   pCore[2] = pCore[0];
+   if (groupWidth > 1 && maxSymsPerKey >= 4)
+   pCore[3] = pCore[1];
+
+   /* ABABCDE... -> ABABCDECDE */
+   idx = 2 + groupWidth;
+   while (groupWidth > 2 &&
+   idx < maxSymsPerKey &&
+   idx < groupWidth * 2)
+   {
+   pCore[idx] = pCore[idx - groupWidth + 2];
+   idx++;
+   }
+   idx = 2 * groupWidth;
+   if (idx < 4)
+   idx = 4;
+   /* 3 or more groups: ABABCDECDEABCDEABCDE */
+   for (n = 0; n < groupWidth && idx < maxSymsPerKey; n++)
+   pCore[idx++] = pXKB[n];
+   }
+
pXKB+= XkbKeyGroupsWidth(xkb,key);
nOut+= 2;
if (nGroups>1) {
@@ -507,11 +541,6 @@ CARD8  keysPerMod[XkbNumModifiers];
}
pXKB+= XkbKeyGroupsWidth(xkb,key);
}
-   if (!pCore[2] && !pCore[3] && maxSymsPerKey >= 6 &&
-(pCore[4] || pCore[5])) {
-pCore[2] = pCore[4];
-pCore[3] = pCore[5];
-   }
}
if (keyc->modifierMap[key]!=0) {
register unsigned bit,i,mask;
-- 
1.5.5.2
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] xkb: fix core keyboard map generation. #14373

[Peter Hutterer]

And here's the follow-up, to get rid of the group duplications. Note that
AFAICT, the protocol spec does not cover the case of xkb->core->xkb so we have
to do some guesswork here.

>From 82512610650f2695526d3b1f0c0a26e71ae02637 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Mon, 22 Sep 2008 11:10:46 +0930
Subject: [PATCH] xkb: squash canonical types into explicit ones on core 
reconstruction.

If we update key types from core, and groups 2 - n have a canonical type but
the same symbols as the explicit type of group 1, assume that it was a core
sym duplication according to Section 12.4 of the XKB Protocol Spec.
Ignore the canonical types and pretend there's only one group for the key -
with the explicit key type.

The protocol spec does not cover this case, so we have to guess here.
---
 xkb/XKBMisc.c |   13 ++---
 1 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/xkb/XKBMisc.c b/xkb/XKBMisc.c
index eb5c381..6f63c2b 100644
--- a/xkb/XKBMisc.c
+++ b/xkb/XKBMisc.c
@@ -178,16 +178,23 @@ int   nGroups,tmp,groupsWidth;
}
 }
 
-/* step 7: check for all groups identical or all width 1 */
+/* step 7: check for all groups identical or all width 1
+ *
+ * Special feature: if group 1 has an explicit type and all other groups
+ * have canonical types with same symbols, we assume it's info lost from
+ * the core replication.
+ */
 if (nGroups>1) {
-   Bool sameType,allOneLevel;
+   Bool sameType,allOneLevel, canonical = True;
allOneLevel= (xkb->map->types[types_inout[0]].num_levels==1);
for (i=1,sameType=True;(allOneLevel||sameType)&&(imap->types[types_inout[i]].num_levels==1);
+   if (types_inout[i] > XkbLastRequiredType)
+   canonical = False;
}
-   if ((sameType)&&
+   if (((sameType) || canonical)&&
(!(protected&(XkbExplicitKeyTypesMask&~XkbExplicitKeyType1Mask{
register int s;
Boolidentical;
-- 
1.5.4.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Raw mouse input is distorted

[Peter Hutterer]

On Fri, Sep 19, 2008 at 01:29:58PM +0200, Søren Hauberg wrote:
> I do have a follow-up question (you can't get rid of me that easy :-)
> ). I have modified the 'usbtouchscreen' kernel module such that it can
> use calibration parameters. With this in place, my touchscreen works
> in X with the 'evdev' driver, i.e. out of the box. Do you guys think
> this is the right approach to handling touchscreens in GNU/Linux, or
> would you prefer an X driver for handling touchscreens? I plan on
> posting the kernel patch to the kernel list on Monday unless anybody
> here thinks the problem should be solved in X instead of the kernel.

I'd prefer the fix in the kernel module, as it keeps the X drivers to a
minimum.
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Keymap issues with Pointer+Keys device

[Peter Hutterer]

On Tue, Sep 16, 2008 at 11:58:56AM +0200, Sascha Hlusiak wrote:
> BTW: With MPX, having two key devices attached to the first master device 
> works fine, regarding the keymap. When creating a second master and attaching 
> a keyboard to that, key presses seem to use the keymap of the first master 
> device, so of the other keyboard.

Note that if you're using core clients, this is "intended" behaviour.
Remember that the ClientPointer (CP) always assigns a "primary" master device
to a core client.

So the call order is something like:
Client requests keymap, server replies with CP's keymap.
If you then hit a key on kbd 2, the server notifies the client that the
keymap has changed.
Client requests keymap, server replies with CP's keymap.

oops.

solution: fix the client :)
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 0/3] X Input 1.5 device properties (final patches)

[Peter Hutterer]

Here's the (hopefully) final patches to device properties in the server.
As mentioned in [1], Configure/Query property functionality and requests have
been culled.

Patch 1 removes these requests. An updated inputproto is required as well of
course.
Patch 2 allows property handlers to return status codes instead of just
TRUE/FALSE. These status codes (if != Success) are returned to the client
as errors.
Patch 3 asks handlers before the deletion of a property. This allows a handler
to implement immutable properties.

Updated inputproto and evdev patches that conform to this implementation are
waiting and can be pushed. Documentation update is nearly there and will be
pushed with the pack.

Cheers,
  Peter

[1] http://lists.freedesktop.org/archives/xorg/2008-September/038262.html



___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH 1/3] Xi: remove configure/query device property calls.

[Peter Hutterer]

From: Peter Hutterer <[EMAIL PROTECTED]>

This removes all the meta-information about device properties (pending,
fromClient, range, valid_values, immutable).
---
 Xi/extinit.c   |   58 +--
 Xi/xiproperty.c|  282 
 Xi/xiproperty.h|6 -
 dix/devices.c  |7 +-
 include/exevents.h |   21 +
 include/inputstr.h |   12 +--
 6 files changed, 75 insertions(+), 311 deletions(-)

diff --git a/Xi/extinit.c b/Xi/extinit.c
index 595e358..9d0ca78 100644
--- a/Xi/extinit.c
+++ b/Xi/extinit.c
@@ -211,22 +211,20 @@ static int (*ProcIVector[])(ClientPtr) = {
ProcXChangeDeviceControl,   /* 35 */
 /* XI 1.5 */
 ProcXListDeviceProperties,  /* 36 */
-ProcXQueryDeviceProperty,   /* 37 */
-ProcXConfigureDeviceProperty,   /* 38 */
-ProcXChangeDeviceProperty,  /* 39 */
-ProcXDeleteDeviceProperty,  /* 40 */
-ProcXGetDeviceProperty, /* 41 */
+ProcXChangeDeviceProperty,  /* 37 */
+ProcXDeleteDeviceProperty,  /* 38 */
+ProcXGetDeviceProperty, /* 39 */
 /* XI 2 */
-ProcXQueryDevicePointer,/* 42 */
-ProcXWarpDevicePointer, /* 43 */
-ProcXChangeDeviceCursor,/* 44 */
-ProcXChangeDeviceHierarchy, /* 45 */
-ProcXChangeWindowAccess,/* 46 */
-ProcXQueryWindowAccess, /* 47 */
-ProcXSetClientPointer,  /* 48 */
-ProcXGetClientPointer,  /* 49 */
-ProcXiSelectEvent,  /* 50 */
-ProcXExtendedGrabDevice /* 51 */
+ProcXQueryDevicePointer,/* 40 */
+ProcXWarpDevicePointer, /* 41 */
+ProcXChangeDeviceCursor,/* 42 */
+ProcXChangeDeviceHierarchy, /* 43 */
+ProcXChangeWindowAccess,/* 44 */
+ProcXQueryWindowAccess, /* 45 */
+ProcXSetClientPointer,  /* 46 */
+ProcXGetClientPointer,  /* 47 */
+ProcXiSelectEvent,  /* 48 */
+ProcXExtendedGrabDevice /* 49 */
 };
 
 /* For swapped clients */
@@ -268,21 +266,19 @@ static int (*SProcIVector[])(ClientPtr) = {
SProcXGetDeviceControl,  /* 34 */
SProcXChangeDeviceControl,   /* 35 */
 SProcXListDeviceProperties,  /* 36 */
-SProcXQueryDeviceProperty,   /* 37 */
-SProcXConfigureDeviceProperty,   /* 38 */
-SProcXChangeDeviceProperty,  /* 39 */
-SProcXDeleteDeviceProperty,  /* 40 */
-SProcXGetDeviceProperty, /* 41 */
-SProcXQueryDevicePointer,/* 42 */
-SProcXWarpDevicePointer, /* 43 */
-SProcXChangeDeviceCursor,/* 44 */
-SProcXChangeDeviceHierarchy, /* 45 */
-SProcXChangeWindowAccess,/* 46 */
-SProcXQueryWindowAccess, /* 47 */
-SProcXSetClientPointer,  /* 48 */
-SProcXGetClientPointer,  /* 49 */
-SProcXiSelectEvent,  /* 50 */
-SProcXExtendedGrabDevice /* 51 */
+SProcXChangeDeviceProperty,  /* 37 */
+SProcXDeleteDeviceProperty,  /* 38 */
+SProcXGetDeviceProperty, /* 39 */
+SProcXQueryDevicePointer,/* 40 */
+SProcXWarpDevicePointer, /* 41 */
+SProcXChangeDeviceCursor,/* 42 */
+SProcXChangeDeviceHierarchy, /* 43 */
+SProcXChangeWindowAccess,/* 44 */
+SProcXQueryWindowAccess, /* 45 */
+SProcXSetClientPointer,  /* 46 */
+SProcXGetClientPointer,  /* 47 */
+SProcXiSelectEvent,  /* 48 */
+SProcXExtendedGrabDevice /* 49 */
 };
 
 /*
@@ -480,8 +476,6 @@ SReplyIDispatch(ClientPtr client, int len, xGrabDeviceReply 
* rep)
 (xChangeDeviceControlReply *) rep);
 else if (rep->RepType == X_ListDeviceProperties)
 SRepXListDeviceProperties(client, len, 
(xListDevicePropertiesReply*)rep);
-else if (rep->RepType == X_QueryDeviceProperty)
-SRepXQueryDeviceProperty(client, len, (xQueryDevicePropertyReply*)rep);
 else if (rep->RepType == X_GetDeviceProperty)
SRepXGetDeviceProperty(client, len, (xGetDevicePropertyReply *) rep);
 else i

[PATCH 2/3] Xi: allow Set/GetProperties to return a status, and honour this status code.

[Peter Hutterer]

From: Peter Hutterer <[EMAIL PROTECTED]>

If a property handler now bails out, return the error code to the caller. This
allows to be slightly more specific with the errors.
---
 Xi/xiproperty.c|   63 +--
 dix/devices.c  |7 ++---
 include/exevents.h |   16 ++--
 include/inputstr.h |   10 
 4 files changed, 57 insertions(+), 39 deletions(-)

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 425cd75..bd130d1 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -94,11 +94,11 @@ XIInitKnownProperties(void)
  */
 long
 XIRegisterPropertyHandler(DeviceIntPtr dev,
-  Bool (*SetProperty) (DeviceIntPtr dev,
-   Atom property,
-   XIPropertyValuePtr prop),
-  Bool (*GetProperty) (DeviceIntPtr dev,
-   Atom property))
+  int (*SetProperty) (DeviceIntPtr dev,
+  Atom property,
+  XIPropertyValuePtr prop),
+  int (*GetProperty) (DeviceIntPtr dev,
+  Atom property))
 {
 XIPropertyHandlerPtr new_handler;
 
@@ -252,6 +252,7 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 XIPropertyValuePtr  prop_value;
 XIPropertyValueRec  new_value;
 Booladd = FALSE;
+int rc;
 
 size_in_bytes = format >> 3;
 
@@ -325,12 +326,16 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 XIPropertyHandlerPtr handler = dev->properties.handlers;
 while(handler)
 {
-if (handler->SetProperty &&
-!handler->SetProperty(dev, prop->propertyName, &new_value))
+if (handler->SetProperty)
 {
-if (new_value.data)
-xfree (new_value.data);
-return (BadValue);
+rc = handler->SetProperty(dev, prop->propertyName,
+  &new_value);
+if (rc != Success)
+{
+if (new_value.data)
+xfree (new_value.data);
+return (rc);
+}
 }
 handler = handler->next;
 }
@@ -349,7 +354,6 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 dev->properties.properties = prop;
 }
 
-
 if (sendevent)
 {
 event.type  = DevicePropertyNotify;
@@ -363,16 +367,17 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 return(Success);
 }
 
-/**
- *
- */
-_X_EXPORT XIPropertyValuePtr
-XIGetDeviceProperty (DeviceIntPtr dev, Atom property)
+int
+XIGetDeviceProperty (DeviceIntPtr dev, Atom property, XIPropertyValuePtr 
*value)
 {
 XIPropertyPtr   prop = XIFetchDeviceProperty (dev, property);
+int rc;
 
 if (!prop)
-return NULL;
+{
+*value = NULL;
+return BadAtom;
+}
 
 /* If we can, try to update the property value first */
 if (dev->properties.handlers)
@@ -381,11 +386,20 @@ XIGetDeviceProperty (DeviceIntPtr dev, Atom property)
 while(handler)
 {
 if (handler->GetProperty)
-handler->GetProperty(dev, prop->propertyName);
+{
+rc = handler->GetProperty(dev, prop->propertyName);
+if (rc != Success)
+{
+*value = NULL;
+return rc;
+}
+}
 handler = handler->next;
 }
 }
-return &prop->value;
+
+*value = &prop->value;
+return Success;
 }
 
 int
@@ -489,6 +503,8 @@ ProcXChangeDeviceProperty (ClientPtr client)
  stuff->type, (int)format,
  (int)mode, len, (pointer)&stuff[1], TRUE);
 
+if (rc != Success)
+client->errorValue = stuff->property;
 return rc;
 }
 
@@ -570,9 +586,12 @@ ProcXGetDeviceProperty (ClientPtr client)
 return(client->noClientException);
 }
 
-prop_value = XIGetDeviceProperty(dev, stuff->property);
-if (!prop_value)
-return BadAtom;
+rc = XIGetDeviceProperty(dev, stuff->property, &prop_value);
+if (rc != Success)
+{
+client->errorValue = stuff->property;
+return rc;
+}
 
 /* If the request type and actual type don't match. Return the
 property information, but not the data. */
diff --git a/dix/devices.c b/dix/devices.c
in

[PATCH 3/3] Xi: ask handlers before deletion of property.

[Peter Hutterer]

From: Peter Hutterer <[EMAIL PROTECTED]>

Add "delete" parameter to SetProperty handler, handlers can refuse to delete a
property by returning something other than Success.
---
 Xi/xiproperty.c|   20 ++--
 dix/devices.c  |6 +-
 include/exevents.h |3 ++-
 include/inputstr.h |3 ++-
 4 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index bd130d1..50a4caf 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -96,7 +96,8 @@ long
 XIRegisterPropertyHandler(DeviceIntPtr dev,
   int (*SetProperty) (DeviceIntPtr dev,
   Atom property,
-  XIPropertyValuePtr prop),
+  XIPropertyValuePtr prop,
+  BOOL delete),
   int (*GetProperty) (DeviceIntPtr dev,
   Atom property))
 {
@@ -218,11 +219,26 @@ XIDeleteDeviceProperty (DeviceIntPtr device, Atom 
property, Bool fromClient)
 {
 XIPropertyPtr   prop, *prev;
 devicePropertyNotifyevent;
+int rc;
 
 for (prev = &device->properties.properties; (prop = *prev); prev = 
&(prop->next))
 if (prop->propertyName == property)
 break;
 
+/* Ask handlers if we may delete the property */
+if (fromClient && device->properties.handlers)
+{
+XIPropertyHandlerPtr handler = device->properties.handlers;
+while(handler)
+{
+rc = handler->SetProperty(device, prop->propertyName,
+  &prop->value, TRUE);
+if (rc != Success)
+return (rc);
+handler = handler->next;
+}
+}
+
 if (prop)
 {
 *prev = prop->next;
@@ -329,7 +345,7 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 if (handler->SetProperty)
 {
 rc = handler->SetProperty(dev, prop->propertyName,
-  &new_value);
+  &new_value, FALSE);
 if (rc != Success)
 {
 if (new_value.data)
diff --git a/dix/devices.c b/dix/devices.c
index fb63473..c0ff019 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -102,10 +102,14 @@ DevPrivateKey UnusedClassesPrivateKey = 
&UnusedClassesPrivateKeyIndex;
  * DIX property handler.
  */
 static int
-DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
+DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
+  BOOL delete)
 {
 if (property == XIGetKnownProperty(XI_PROP_ENABLED))
 {
+if (delete) /* you're not allowed to delete any server-internal prop */
+return BadAccess;
+
 if (prop->format != 8 || prop->type != XA_INTEGER || prop->size != 1)
 return BadValue;
 
diff --git a/include/exevents.h b/include/exevents.h
index c3a2ad6..b22d433 100644
--- a/include/exevents.h
+++ b/include/exevents.h
@@ -226,7 +226,8 @@ extern long XIRegisterPropertyHandler(
 DeviceIntPtr dev,
 int (*SetProperty) (DeviceIntPtr dev,
 Atom property,
-XIPropertyValuePtr prop),
+XIPropertyValuePtr prop,
+BOOL delete),
 int (*GetProperty) (DeviceIntPtr dev,
 Atom property)
 );
diff --git a/include/inputstr.h b/include/inputstr.h
index 93b3293..0a8bf91 100644
--- a/include/inputstr.h
+++ b/include/inputstr.h
@@ -366,7 +366,8 @@ typedef struct _XIPropertyHandler
 long id;
 int (*SetProperty) (DeviceIntPtr dev,
 Atom property,
-XIPropertyValuePtr prop);
+XIPropertyValuePtr prop,
+BOOL delete);
 int (*GetProperty) (DeviceIntPtr dev,
 Atom property);
 } XIPropertyHandler, *XIPropertyHandlerPtr;
-- 
1.5.4.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 3/3] Xi: ask handlers before deletion of property.

[Peter Hutterer]

On Mon, Sep 22, 2008 at 11:30:59AM +0200, Simon Thum wrote:
>> -DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
>> +DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
>> +  BOOL delete)
>>  {
>>  if (property == XIGetKnownProperty(XI_PROP_ENABLED))
>>  {
>> +if (delete) /* you're not allowed to delete any server-internal 
>> prop */
>> +return BadAccess;
>> +
> Isn't that impossible anyway? If not, how about XI_PROP_MODE?

> In general, I must admit I don't really get the scenario: Client props  
> don't have handlers, and server-side props can only be deleted by  
> in-server code, right?
> So what problem does the patch solve, then?

the scenario here is: xinput --delete-prop "foobar pointer" "Device Enabled"

Without the handler disallowing that, a client could potentially delete
properties that are "owned" by the server or a driver.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?

[Peter Hutterer]

On Tue, Sep 23, 2008 at 02:41:16AM +, Jason Spiro wrote:
> Problem:  Many[1] users have killed X by accident.[2]
> 
> Solution idea: Make it harder to kill X by accident.  E.g. you could
> change the key sequence users must press.
>* Maybe require Control+Alt+Backspace then Control-Alt-Y.[3]
>* Or require Control+K+X pressed simultaneously.

driver kbd: hardcodes Ctrl + Alt + Backspace. (IMHO that's a bug anyway)
driver evdev: the XKB map decides what happens.

In the latter case, all you have to do is change the xkb map. If you can
convice svu to add it to xkeyboard-config, you only need to supply the right
option and you're done with it.

I'm not quite sure what the poll will achieve here.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: How to implement alternate zap key idea (was: Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to?something harder for users to press by accident?)

[Peter Hutterer]

On Tue, Sep 23, 2008 at 04:39:49AM +, Jason Spiro wrote:
> Thanks for the info.  1. So I guess when using evdev, a way to implement my
> Ctrl+Alt+Bksp then Ctrl+Alt+Y idea would be this?:  Ctrl+Alt+Bksp should latch
> some new modifier called ctrl_alt_bksp_was_pressed, and Ctrl+Alt+Y should zap 
> X
> only when that modifier is latched.  Would that work?

maybe. You'd need to look at XKB's compat capabilities there.

Anyway - that's taking the hard way out. 
your claim was that CAB is too easy to hit. So disable it - it could be easily
done at runtime through xkb options. Or put it on ctrl-alt-shift-F12 or
something.

Alternatively, have a client listen to CAB, load the normal xkb behaviour, pop
up a dialog "if you want to kill the server, hit CAB now". (this is just idle
thinking)

> As for the Ctrl+K+X idea (which I don't know is as safe; 

AFAIK, XKB will only handle combinations with modifiers. sequential key combos
must be done in a client.

> 2. is it possible that a heavy pet sitting on the keyboard and depressing all 
> keys at once could cause
> X to think Ctrl+K+X was pressed?), 

yes. and those users with a pet octopus better choose a 9-key combo. Ha, 
serves them octopodiformes right for having 2 fingers less than us!

There is a thing such as cost/effort. stop your pet sitting on the keyboard,
or disable zap.

> 3. are kbd and evdev each able to detect such a key combination? 

both are designed to handle key events - yes.

> 4. Are the majority of PS/2 and USB keyboards able to transmit such three-key 
> combos reliably?  

they are designed to handle keyboard entry - yes.

> 5. Do most users know how to press multi-letter key combinations?

Depends on your definition of "most" and of "users". I know a fair few that
would go looking for a post box when you start talking about multi-letter
combinations.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: current git head of Xserver segfaults on a keyhit

[Peter Hutterer]

On Mon, Sep 22, 2008 at 08:08:37PM +0200, Lukas Hejtmanek wrote:
> the current git head of the Xserver segfaults on any keystroke. Trace is
> attached:

Can I have a log please?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

[Peter Hutterer]

One more patch that was missing from the previous patchset.

New file include/xserver-properties.h that includes #defines for the
properties managed by the server.

File is installed as part of the SDK to be included by clients who wish to
manipulate said properties.

This way we don't have to bump inputproto for new properties (e.g. ptr accel
configuration, a "driver" property, etc.)

Cheers,
  Peter


>From 826b6441fe27304a37c0452457ff6c7ba952bfff Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Tue, 23 Sep 2008 16:55:04 +0930
Subject: [PATCH] Push server-known properties into xserver-properties.h.

---
 Xi/xiproperty.c  |1 +
 dix/devices.c|1 +
 include/Makefile.am  |3 ++-
 include/xserver-properties.h |   32 
 4 files changed, 36 insertions(+), 1 deletions(-)
 create mode 100644 include/xserver-properties.h

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 50a4caf..94d5499 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -38,6 +38,7 @@
 #include "swaprep.h"
 
 #include "xiproperty.h"
+#include "xserver-properties.h"
 
 /**
  * Properties used or alloced from inside the server.
diff --git a/dix/devices.c b/dix/devices.c
index c0ff019..a16cd1c 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -86,6 +86,7 @@ SOFTWARE.
 #include "exevents.h"
 #include "listdev.h" /* for CopySwapXXXClass */
 #include "xiproperty.h"
+#include "xserver-properties.h"
 
 /** @file
  * This file handles input device-related stuff.
diff --git a/include/Makefile.am b/include/Makefile.am
index 76c265e..f639048 100644
--- a/include/Makefile.am
+++ b/include/Makefile.am
@@ -53,7 +53,8 @@ sdk_HEADERS = \
windowstr.h \
xkbfile.h   \
xkbsrv.h\
-   xkbstr.h
+   xkbstr.h\
+   xserver-properties.h
 
 nodist_sdk_HEADERS = xorg-server.h
 endif
diff --git a/include/xserver-properties.h b/include/xserver-properties.h
new file mode 100644
index 000..4d602b5
--- /dev/null
+++ b/include/xserver-properties.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright 2008 Red Hat, Inc.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software")
+ * to deal in the software without restriction, including without limitation
+ * on the rights to use, copy, modify, merge, publish, distribute, sub
+ * license, and/or sell copies of the Software, and to permit persons to whom
+ * them Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTIBILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER
+ * IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+
+/* Properties managed by the server. */
+
+#ifndef _XSERVER_PROPERTIES_H_
+#define _XSERVER_PROPERTIES_H_
+
+/* BOOL. 0 - device disabled, 1 - device enabled */
+#define XI_PROP_ENABLED  "Device Enabled"
+
+#endif
-- 
1.5.4.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Keymap issues with Pointer+Keys device

[Peter Hutterer]

On Tue, Sep 23, 2008 at 08:36:13PM +0200, Sascha Hlusiak wrote:
> > Note that if you're using core clients, this is "intended" behaviour.
> > Remember that the ClientPointer (CP) always assigns a "primary" master
> > device to a core client.
> >
> > So the call order is something like:
> > Client requests keymap, server replies with CP's keymap.
> > If you then hit a key on kbd 2, the server notifies the client that the
> > keymap has changed.
> > Client requests keymap, server replies with CP's keymap.
> >
> > oops.
> >
> > solution: fix the client :)
> So, is xev 'broken' then?

yes, because it has to follow the same procedure. Only clients that use
XGetDeviceKeymapping instead of XGetKeyboardMapping can work properly.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Keymap issues with Pointer+Keys device

[Peter Hutterer]

On Wed, Sep 24, 2008 at 02:12:48AM +0300, Daniel Stone wrote:
> Maybe I'm missing something, but can we not do as SwitchCoreKeyboard
> used to do, and have all requests for keymap/whatever act on the device
> that last sent a key event to that client?

right, we could. The equivalent now would be SetClientPointer, which the
server would invoke after each key and/or button event.

The reason why I was against it so far is because it only helps in the short
run, and even then only to some extent. It sacrifices openly broken but
predictable behaviour for less broken but unpredictable behaviour.

The correct approach is to have a WM that requests SetClientPointer when
appropriate.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: What's wrong with xkbcomp?

[Peter Hutterer]

On Tue, Sep 23, 2008 at 04:31:26PM -0700, Dan Nicholson wrote:
> I thought someone (you or keithp?) was going to just put xkbcomp into
> the server. Did anything ever happen with that? Just curious.

The usual lack of time issue. If you find the time to do it - go for it.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

[Peter Hutterer]

On Tue, Sep 23, 2008 at 09:02:34PM +0200, Simon Thum wrote:
> one more thing: A Handler already consists of getter and setter, so  
> there's an incentive to abstracting 'hey thats my property' on the  
> handler side anyway. So why load deletion onto the setter as a special  
> case of modification? I think it would be cleaner to have an own  
> 'sub-handler' for deletion.
>
> Or, since 99% of in-server code will just protect its props (at least,  
> no other use case comes to my mind), we could make it a property flag  
> again. I understand you want to get rid of it, but I think this one  
> could save some code on the handlers side. Mostly code which isn't  
> exactly DRY.

Right, I can see your point. How about the patch below (untested)? It's on top
of the other patches and adds a DeleteProperty handler, and a deletable flag.

If deletable is FALSE, the prop can only be deleted by the server/a driver,
and even then only if all handlers agree.

>From aa3b6cf0bd533bc264f3acddf14222a6e04f9d44 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Wed, 24 Sep 2008 10:18:14 +0930
Subject: [PATCH] Xi: add "deletable" flag to properties, add DeleteProperty 
handler.

Deletable properties may be deleted, if the handlers allow it.

Non-deletable properties may be deleted by a driver/server if all handlers
allow it. A client cannot delete these properties.
---
 Xi/xiproperty.c|   34 ++
 dix/devices.c  |9 +++--
 include/exevents.h |   13 ++---
 include/inputstr.h |6 --
 4 files changed, 43 insertions(+), 19 deletions(-)

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 94d5499..1e4ed46 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -97,10 +97,11 @@ long
 XIRegisterPropertyHandler(DeviceIntPtr dev,
   int (*SetProperty) (DeviceIntPtr dev,
   Atom property,
-  XIPropertyValuePtr prop,
-  BOOL delete),
+  XIPropertyValuePtr prop),
   int (*GetProperty) (DeviceIntPtr dev,
-  Atom property))
+  Atom property),
+  int (*DeleteProperty) (DeviceIntPtr dev,
+ Atom property))
 {
 XIPropertyHandlerPtr new_handler;
 
@@ -111,6 +112,7 @@ XIRegisterPropertyHandler(DeviceIntPtr dev,
 new_handler->id = XIPropHandlerID++;
 new_handler->SetProperty = SetProperty;
 new_handler->GetProperty = GetProperty;
+new_handler->DeleteProperty = DeleteProperty;
 new_handler->next = dev->properties.handlers;
 dev->properties.handlers = new_handler;
 
@@ -155,6 +157,7 @@ XICreateDeviceProperty (Atom property)
 prop->value.format = 0;
 prop->value.size   = 0;
 prop->value.data   = NULL;
+prop->deletable= TRUE;
 
 return prop;
 }
@@ -220,20 +223,23 @@ XIDeleteDeviceProperty (DeviceIntPtr device, Atom 
property, Bool fromClient)
 {
 XIPropertyPtr   prop, *prev;
 devicePropertyNotifyevent;
-int rc;
+int rc = Success;
 
 for (prev = &device->properties.properties; (prop = *prev); prev = 
&(prop->next))
 if (prop->propertyName == property)
 break;
 
+if (fromClient && !prop->deletable)
+return BadAccess;
+
 /* Ask handlers if we may delete the property */
-if (fromClient && device->properties.handlers)
+if (device->properties.handlers)
 {
 XIPropertyHandlerPtr handler = device->properties.handlers;
 while(handler)
 {
-rc = handler->SetProperty(device, prop->propertyName,
-  &prop->value, TRUE);
+if (handler->DeleteProperty)
+rc = handler->DeleteProperty(device, prop->propertyName);
 if (rc != Success)
 return (rc);
 handler = handler->next;
@@ -346,7 +352,7 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 if (handler->SetProperty)
 {
 rc = handler->SetProperty(dev, prop->propertyName,
-  &new_value, FALSE);
+  &new_value);
 if (rc != Success)
 {
 if (new_value.data)
@@ -420,6 +426,18 @@ XIGetDeviceProperty (DeviceIntPtr dev, Atom property, 
XIPropertyValuePtr *value)
 }
 
 int
+XISetDevicePropertyDeletable(DeviceI

Re: What's wrong with xkbcomp?

[Peter Hutterer]

On Wed, Sep 24, 2008 at 02:42:29AM +0100, Simos Xenitellis wrote:
> The next step in replacing xkbcomp would be to list any of the
> structures we many want to eliminate or reduce some of the fields.
> 
> xkb_keymap
> | xkb_keycodes
> | xkb_types
> | xkb_compatibility
> | xkb_symbols
> | xkb_geometry


There's two stages involved.
Step 1: is to go from the RMLVO in setxkbmap into a xkb_keymap. This includes
trawling through rules files, etc.
Step 2: is to parse the xkb_keymap into the server's internal format.

Optimisations include:
For Step 1: 
   - leave the xkb_keymap around instead of regenerating it.
   - connect RMLVO and Ktcsg so you can get the former from the latter. This
 way you can check if an xkb_keymap is correct for a given RMLVO.
For Step 2: 
   - don't go through the fork, let the server parse it.
   - xkb_geometry isn't used by the server until a client actually requests it
 (AFAIK). maybe parsing can be deferred?
   - the xkb_XXX could be split into several files, only requiring reparsing
 e.g. xkb_symbols if the symbols change.
 
Cheers,
  Peter

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 0/3] X Input 1.5 device properties (final patches)

[Peter Hutterer]

On Wed, Sep 24, 2008 at 07:48:57AM +0200, Simon Thum wrote:
>> If deletable is FALSE, the prop can only be deleted by the server/a driver,
>> and even then only if all handlers agree.
> That's a bit stricter than what I was looking for. If I want to delete a  
> prop in-server, I'd like be able to avoid asking handlers (as I was  
> before). Otherwise, I'm still forced to implement a delete handler for  
> the sole purpose of giving up the veto at some time. Essentially I need  
> a parallel channel to delete my own props. Boils down to dumping

In the default case (if you do not have a handler) the property will get
deleted. Only if you want to absolutely prohibit anyone from deleting the
prop, then you need a handler.

The reason for the decision is that if two handlers affect the same
property, one handler may be fine with the deletion, the other one not.

>> -if (fromClient && device->properties.handlers)
>> +if (device->properties.handlers)
>
> that part. And maybe rename fromClient to checkHandlers or deletable to  
> clientDeletable, whatever. IOW: If deletable is FALSE and fromClient is  
> TRUE, handlers have to agree.

agreed - clientDeletable is better. I'll amend the patch.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Creating a touch screen driver

[Peter Hutterer]

On Thu, Sep 25, 2008 at 03:19:51PM +0200, Søren Hauberg wrote:
> [...] now I guess I'll  have to write an X driver that'll handle the
> touchscreen. The kernel module I'm targeting is using evdev, so that's the
> API I'll be working against.
>   So, my question is: should I attempt to extend the X11 evdev driver,

yes please. as long as you can keep the parts you need generic (i.e. not
restricted to your screen) evdev is the way to go.

I'll be happy to take patches.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Adjust joystick properties to new property API.

[Peter Hutterer]

ConfigureProperty doesn't exist anymore, ChangeProperty has two parameters
less. SetProperty handler must return Status.
Mark all properties as non-deletable.
---
 src/jstk_properties.c |  103 -
 1 files changed, 34 insertions(+), 69 deletions(-)

diff --git a/src/jstk_properties.c b/src/jstk_properties.c
index 4ef64b7..fff0ffd 100644
--- a/src/jstk_properties.c
+++ b/src/jstk_properties.c
@@ -94,7 +94,7 @@ static Atom prop_button_keys = 0;
 
 
 
-static Bool
+static int
 jstkSetProperty(DeviceIntPtr pJstk, Atom atom, XIPropertyValuePtr val)
 {
 InputInfoPtr  pInfo = pJstk->public.devicePrivate;
@@ -105,31 +105,31 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 {
 #if DEBUG
 if (val->size != 1 || val->format != 8 || val->type != XA_INTEGER)
-return FALSE;
+return BadMatch;
 debug_level = *((INT8*)val->data);
ErrorF("JOYSTICK: DebugLevel set to %d\n", debug_level);
 #endif
 }else if (atom == prop_mouse_enabled)
 {
 if (val->size != 1 || val->format != 8 || val->type != XA_INTEGER)
-return FALSE;
+return BadMatch;
 priv->mouse_enabled = (*((INT8*)val->data)) != 0;
 DBG(1, ErrorF("mouse_enabled set to %d\n", priv->mouse_enabled));
 }else if (atom == prop_keys_enabled)
 {
 if (val->size != 1 || val->format != 8 || val->type != XA_INTEGER)
-return FALSE;
+return BadMatch;
 priv->keys_enabled = (*((INT8*)val->data)) != 0;
 DBG(1, ErrorF("keys_enabled set to %d\n", priv->keys_enabled));
 }else if (atom == prop_axis_deadzone)
 {
 if (val->size > MAXAXES || val->format != 32 || val->type != 
XA_INTEGER)
-return FALSE;
+return BadMatch;
 if (val->size == 1) { /* Single value to be applied to all axes */
 INT32 value;
 value = *((INT32*)val->data);
 if (value < 0) value = (-value);
-if (value > 3) return FALSE;
+if (value > 3) return BadValue;
 for (i =0; iaxis[i].deadzone = value;
 DBG(1, ErrorF("Deadzone of all axes set to %d\n",value));
@@ -138,7 +138,7 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 values = (INT32*)val->data;
 for (i =0; isize; i++) /* Fail, if one value is out of range 
*/ 
 if (values[i] > 3 || values[i] < -3)
-return FALSE;
+return BadValue;
 for (i =0; isize; i++) {
 priv->axis[i].deadzone = 
(values[i]<0)?(-values[i]):(values[i]);
 DBG(1, ErrorF("Deadzone of axis %d set to %d\n",i, 
priv->axis[i].deadzone));
@@ -148,7 +148,7 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 {
 INT8 *values;
 if (val->size > MAXAXES || val->format != 8 || val->type != XA_INTEGER)
-return FALSE;
+return BadMatch;
 values = (INT8*)val->data;
 for (i =0; isize; i++) {
 priv->axis[i].type = values[i];
@@ -158,7 +158,7 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 {
 INT8 *values;
 if (val->size > MAXAXES || val->format != 8 || val->type != XA_INTEGER)
-return FALSE;
+return BadMatch;
 values = (INT8*)val->data;
 for (i =0; isize; i++) {
 priv->axis[i].mapping = values[i];
@@ -167,20 +167,20 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 }else if (atom == prop_axis_amplify)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }else if (atom == prop_axis_keys_low)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }else if (atom == prop_axis_keys_high)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }else if (atom == prop_button_mapping)
 {
 INT8 *values;
 if (val->size > MAXBUTTONS || val->format != 8 || val->type != 
XA_INTEGER)
-return FALSE;
+return BadMatch;
 values = (INT8*)val->data;
 for (i =0; isize; i++) {
 priv->button[i].mapping = values[i];
@@ -189,39 +189,30 @@ jstkSetProperty(DeviceIntPtr pJstk, Atom atom, 
XIPropertyValuePtr val)
 }else if (atom == prop_button_buttonnumber)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }else if (atom == prop_button_amplify)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }else if (atom == prop_button_keys)
 {
 /* FIXME */
-return FALSE;
+return BadValue;
 }
 
 /* property not handled, report success */
-return TRUE;
-}
-
-static Bool
-jstkGetProperty(DeviceIntPtr pJstk, Atom property)
-{
-return TRUE;
+return Success;
 }

Re: Extra pointer motion with current git xf86-input-synaptics

[Peter Hutterer]

On Sat, Sep 27, 2008 at 06:10:32PM +0100, Magnus Kessler wrote:
> Since updating to the current git version of xorg-server, inputproto and 
> xf86-input-synaptics I observe extra pointer movements for every event 
> generated by the touchpad.
> 
> Even when not touching the pad and using the buttons instead the pointer 
> moves 1 pixel to the top-left which each event (x and y coordinate decrease 
> by 1 every time). Equally, each event generated from touching the pad seems 
> to have this extra movement towards the top-left of the screen.

what hardware do you have?
Any special options in xorg.conf/the fdi file?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Extra pointer motion with current git xf86-input-synaptics

[Peter Hutterer]

On Sun, Sep 28, 2008 at 08:23:51AM +0100, Magnus Kessler wrote:
> I have just reverted the part of commit  
> c405a69f83dab77cfe6c76f718a3ca5614a85918 that passes the actual x/y ranges 
> to xf86InitValuatorAxisStruct. Now the extra movement is gone, but I get a 
> somewhat quicker cursor movement than I was used to before. This would be 
> due to the other recent changes that set new default values for the 
> acceleration parameters, of course.

> I'm trying to see where in the valuators are actually used inside the X 
> server. With a smaller range than [0, -1] some rounding error (?) seems to 
> create that extra pixel offset for each event processed. This is on a 
> 64-bit platform, in case this is important.

Check out GetPointerEvents in xserver/dix/getevents.c. 

We take valuator coordinates, scale them to screen coords based on the axis
information and then scale them back to device coords*.

The screen coords are used to move the cursor and the scaling is done based on
the axis ranges. Hence the different acceleration when you change the axis
range to 0,-1 (in which case the screen coords are used as axis ranges).

On top of it all, pointer acceleration kicks in as well. So the problem you're
experiencing (i don't see it on similar hardware) can be:
1. in-driver scaling issues
2. server scaling issues
3. pointer accel issues

1. is easy to figure out by putting xf86Msg(X_ERROR, "...") before
xf86PostMotionEvent and xf86PostButtonEvent in the driver and checking the 
valuators. If they change, the driver is to blame.

2 and 3 are a bit harder to find out, but narrowing it down to 1 or [2,3]
would be good already.

Cheers,
  Peter

* the last step is buggy, we lose information here :(
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] xf86-input-synaptics: fix creation of repeater fifo

[Peter Hutterer]

On Sun, Sep 28, 2008 at 10:09:01AM +0100, Magnus Kessler wrote:
> The creation of the repeater fifo in the synaptics driver looks dubious. The 
> file mode should be ORed with the S_IFIFO flag and the dev parameter should 
> be null. The mknod(3p) man page suggests using mkfifo instead.

Agreed.

>[...]
> repeater = xf86SetStrOption(local->options, "Repeater", NULL);
> if (repeater) {
>   /* create repeater fifo */
>-  status = mknod(repeater, 666, S_IFIFO);
>-  if ((status != 0) && (status != EEXIST)) {
>+  if (mkfifo(repeater, S_IWUSR|S_IRUSR|S_IWGRP|S_IRGRP|S_IWOTH|S_IROTH)) {
>   xf86Msg(X_ERROR, "%s can't create repeater fifo\n", local->name);
>   } else {
>   /* open the repeater fifo */


Any special reason for dropping the EEXIST case?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] xf86-input-synaptics: fix creation of repeater fifo

[Peter Hutterer]

On Sun, Sep 28, 2008 at 03:11:46PM +0100, Magnus Kessler wrote:
> Testing status against EEXIST is wrong and we should check errno instead if 
> we want to allow the use of an existing file. However, since we pass a file 
> name that in principle could be any existing file (not just fifos) is there 
> any guarantee that we can later actually use the fifo?

Thanks. There is no guarantee that we can use it, but at the same time the
use-case where the pipe already exists is common.
In the simple case of a server restart, the first mkfifo command succeeds but
the second fails with EEXIST. So the pipe is still there and should be used.
Admittedly, it might be a good idea to clean up after ourselves and delete the
fifo if we have created it in the first place. What about the (compile-tested)
code below?

Cheers,
  Peter

diff --git a/src/synaptics.c b/src/synaptics.c
index 18168e0..e5cb7f0 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -512,6 +512,9 @@ static void set_repeater_fifo(LocalDevicePtr local)
if (status && (errno != EEXIST)) {
xf86Msg(X_ERROR, "%s can't create repeater fifo\n", local->name);
} else {
+if (!status)
+priv->fifo_path = strdup(repeater); /* for unlinking later */
+
/* open the repeater fifo */
optList = xf86NewOption("Device", repeater);
if ((priv->fifofd = xf86OpenSerial(optList)) == -1) {
@@ -608,6 +611,7 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
 DBG(9, XisbTrace(priv->comm.buffer, 1));
 
 priv->fifofd = -1;
+priv->fifo_path = NULL;
 set_repeater_fifo(local);
 
 if (!QueryHardware(local)) {
@@ -655,6 +659,13 @@ static void SynapticsUnInit(InputDriverPtr drv,
 InputInfoPtr   local,
 intflags)
 {
+SynapticsPrivate *priv = (SynapticsPrivate *) (local->private);
+
+if (priv->fifo_path)
+{
+unlink(priv->fifo_path);
+xfree(priv->fifo_path);
+}
 xfree(local->private);
 local->private = NULL;
 xf86DeleteInput(local, 0);
diff --git a/src/synapticsstr.h b/src/synapticsstr.h
index e5202d1..d93e279 100644
--- a/src/synapticsstr.h
+++ b/src/synapticsstr.h
@@ -96,6 +96,7 @@ typedef struct _SynapticsPrivateRec
 
 struct CommData comm;
 int fifofd;/* fd for fifo */
+char *fifo_path;/* path to fifo for unlinking */
 
 SynapticsMoveHistRec move_hist[SYNAPTICS_MOVE_HISTORY]; /* movement 
history */
 int hist_index;/* Last added entry in move_hist[] */
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Extra pointer motion with current git xf86-input-synaptics

[Peter Hutterer]

On Sun, Sep 28, 2008 at 07:26:06PM +0200, Simon Thum wrote:
>> The screen coords are used to move the cursor and the scaling is done based 
>> on
>> the axis ranges. Hence the different acceleration when you change the axis
>> range to 0,-1 (in which case the screen coords are used as axis ranges).
> To me, this case sounds like a rounding error piling up.
>
> What about:
>
> rescaleValuatorAxis(int coord, AxisInfoPtr from, AxisInfoPtr to,
> int defmax)
> {
> [...]
> return (int)(((float)(coord - fmin) + 0.5f) * (tmax - tmin + 1) /
>  (fmax - fmin + 1)) + tmin;


The patch below should fix another issue, the scaling from device -> core ->
device. With the patch below, x/y is now used as it is reported by the device
(unless a screen cross happens).

diff --git a/dix/getevents.c b/dix/getevents.c
index 166ab4e..f2086e8 100644
--- a/dix/getevents.c
+++ b/dix/getevents.c
@@ -919,17 +919,22 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev, 
int type, int buttons,
 master->last.valuators[1] = pDev->last.valuators[1];
 }
 
+/* Crossed screen? Scale back to device coordiantes */
 if(cx != pDev->last.valuators[0])
+{
+scr = miPointerGetScreen(pDev);
+x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
+pDev->valuator->axes + 0, scr->width);
 cx = pDev->last.valuators[0];
+}
 if(cy != pDev->last.valuators[1])
+{
+scr = miPointerGetScreen(pDev);
 cy = pDev->last.valuators[1];
+y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
+pDev->valuator->axes + 1, scr->height);
+}
 
-/* scale x/y back to device coordinates */
-scr = miPointerGetScreen(pDev);
-x = rescaleValuatorAxis(pDev->last.valuators[0], NULL,
-pDev->valuator->axes + 0, scr->width);
-y = rescaleValuatorAxis(pDev->last.valuators[1], NULL,
-pDev->valuator->axes + 1, scr->height);
 
 updateMotionHistory(pDev, ms, first_valuator, num_valuators,
 &pDev->last.valuators[first_valuator]);
@@ -938,7 +943,6 @@ GetPointerEvents(EventList *events, DeviceIntPtr pDev, int 
type, int buttons,
 &pDev->last.valuators[first_valuator]);
 
 /* Update the valuators with the true value sent to the client*/
-/* FIXME: we lose subpixel precision here. */
 if(v0) *v0 = x;
 if(v1) *v1 = y;
 
-- 
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Mon, Sep 29, 2008 at 09:42:22AM +0200, Søren Hauberg wrote:
>   I'm trying to differentiate touchpads from touchscreens in the evdev
> driver. Both types of devices has absolute axis, and emit the
> BTN_TOUCH signal. So, I need something else to tell them apart.
> Unfortunately, I don't have access to a touchpad (the only one I have
> is broken), so I can't figure out if such a device has other
> interesting properties. So, my question is: does touchpads have
> buttons, i.e. do they emit BTN_LEFT? Touchscreens don't (at least the
> ones using the 'usbtouchscreen' kernel module doesn't), so I might be
> able to use this as a differentiator.

Here's the output of my touchpad, it advertises LMR button.
I'd say that most if not all touchpads have a physical button too, so no button 
would probably be a good indicator for a touchscreen.

[EMAIL PROTECTED]:~$ sudo ./evtest /dev/input/event5
Input driver version is 1.0.0
Input device ID: bus 0x11 vendor 0x2 product 0x7 version 0x81b1
Input device name: "SynPS/2 Synaptics TouchPad"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
Event code 272 (LeftBtn)
Event code 273 (RightBtn)
Event code 274 (MiddleBtn)
Event code 325 (ToolFinger)
Event code 330 (Touch)
Event code 333 (Tool Doubletap)
Event code 334 (Tool Tripletap)
  Event type 3 (Absolute)
Event code 0 (X)
  Value  1
  Min 1472
  Max 5472
Event code 1 (Y)
  Value   5855
  Min 1408
  Max 4448
Event code 24 (Pressure)
  Value  0
  Min0
  Max  255
Event code 28 (Tool Width)
  Value  0
  Min0
  Max0
Testing ... (interrupt to exit)

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

Søren:

On Mon, Sep 29, 2008 at 01:29:35PM +0200, Søren Hauberg wrote:
> > Sorry, I wanted to suggest that in reply but missed it. Anyway, be aware
> > that as your patch is now, you're also triggering on absolute axes you can't
> > handle/don't know. I'd consider that a regression.
> 
> Ahh, I (think I) see. The attached patch should handle this. 

a few comments to your patch:

@@ -208,14 +224,23 @@
 break;
 
case EV_ABS:
+abs = 1;

this is the problem here. You may be defining abs even if we don't have
absolute x/y axes. Just leave that bit as it is.

case BTN_TOOL_FINGER:
case BTN_TOOL_MOUSE:
case BTN_TOOL_LENS:
+   was_touched = 1;
pEvdev->tool = value ? ev.code : 0;
break;

why set was_touched for BTN_TOOL_LENS, etc? It'd be better to move this line
up to BTN_TOUCH.
Also - maybe you can find a way to work around was_touched and use
pEvdev->tool to indicate if a touch is active?
Or - even better, you hook into the default case of the switch statement for
BTN_TOUCH and let the already existing code handle buttons, draglock, etc.
(right now you're missing out on this).
Not 100% sure myself if devices like wacom send BTN_TOUCH and if that would
then interfere with your code. Something to look at I guess.

+} else if (pEvdev->flags & EVDEV_TOUCHSCREEN) {
+if (was_touched) {
+xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2,
+   pEvdev->abs_x, pEvdev->abs_y);

Maybe only send a motion event when the coordinates actually have changed?

>   Also, I've hardcoded my own calibration parameters into the patch to
> ease testing. This is obviously not usable in general. If I want to
> use device properties (that's what I've been told they're called) to
> set these parameters, how would I go about doing that?

evdev already has the code for device properties in e.g. draglock.c. Best to
just check it but maybe wait a day or so, I have changes in the pipe that
restructure the use of DP in evdev. The API is the same, but the handler
registration is a bit different.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Mon, Sep 29, 2008 at 03:08:00PM +0200, Søren Hauberg wrote:
> > Look at EvdevInitProperties(). Touchscreen-specifics should be only
> > available on
> > touchscreens, of course.
> 
> This stuff seems to only be in git. It's not in any releases, right?

Yes, it's only in git. The property API was moving around until last week and
only just settled (hopefully anyway).
For new features it's generally best to look at the git driver, the
differences between 2.0 and git are quite significant in some ways.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

.pc files for input drivers

[Peter Hutterer]

Just to get a general opinion: with each driver having their own properties,
it's a good idea to let the driver install a .h file listing all property
names. see synaptics-properties.h, evdev-properties.h and probably more to
come.

Anyone opposed to a follow-up patch to install the .pc file?
If not, xorg-.pc or just.pc?

Cheers,
  Peter

>From 0351d0aad80b6400381b8e32a73228987fb38ab9 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Fri, 26 Sep 2008 10:42:05 +0930
Subject: [PATCH] Add evdev.pc for compiler flags if compiling with 
evdev-properties.h included.

---
 Makefile.am  |7 +--
 configure.ac |   13 -
 evdev.pc.in  |7 +++
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 evdev.pc.in

diff --git a/Makefile.am b/Makefile.am
index 11064e0..7c85f00 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,9 +19,12 @@
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 AUTOMAKE_OPTIONS = foreign
-SUBDIRS = src man
+SUBDIRS = src man include
 
-EXTRA_DIST = ChangeLog autogen.sh
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = evdev.pc
+
+EXTRA_DIST = ChangeLog autogen.sh evdev.pc.in
 
 MAINTAINERCLEANFILES=ChangeLog
 
diff --git a/configure.ac b/configure.ac
index 5a29874..c048059 100644
--- a/configure.ac
+++ b/configure.ac
@@ -52,6 +52,13 @@ AC_ARG_WITH(xorg-module-dir,
 inputdir=${moduledir}/input
 AC_SUBST(inputdir)
 
+AC_ARG_WITH(xorg-sdk-dir,
+AC_HELP_STRING([--with-xorg-sdk-dir=DIR],
+   [Default xorg SDK directory 
[[default=$includedir/xorg]]]),
+[includedir="$withval"],
+[includedir="$includedir/xorg"])
+AC_SUBST([includedir])
+
 # Checks for extensions
 XORG_DRIVER_CHECK_EXT(XINPUT, inputproto)
 
@@ -70,4 +77,8 @@ AC_HEADER_STDC
 XORG_MANPAGE_SECTIONS
 XORG_RELEASE_VERSION
 
-AC_OUTPUT([Makefile src/Makefile man/Makefile])
+AC_OUTPUT([Makefile
+   src/Makefile
+   man/Makefile
+   include/Makefile
+   evdev.pc])
diff --git a/evdev.pc.in b/evdev.pc.in
new file mode 100644
index 000..a8de102
--- /dev/null
+++ b/evdev.pc.in
@@ -0,0 +1,7 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+Name: evdev
+Description: X.Org evdev input driver.
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
-- 
1.5.4.3


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [patch 3/4] Update for MPX changes

[Peter Hutterer]

On Mon, Sep 29, 2008 at 11:01:44PM +0100, [EMAIL PROTECTED] wrote:
> @@ -79,7 +79,7 @@ miPointerScreenFuncRec g_winPointerCurso
>  
>  
>  static void
> -winPointerWarpCursor (ScreenPtr pScreen, int x, int y)
> +winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
>  {
>winScreenPriv(pScreen);
>RECT   rcClient;
> @@ -119,7 +119,7 @@ winPointerWarpCursor (ScreenPtr pScreen,
>  }
>  
>/* Call the mi warp procedure to do the actual warping in X. */
> -  miPointerWarpCursor (pScreen, x, y);
> +  miPointerWarpCursor (inputInfo.pointer, pScreen, x, y);

That should be miPointerWarpCursor(pDev, pScreen, x, y); 
Not that it matters much if you have only one cursor anyway, but still.

Rest looks ok, though I didn't even compile-tested it.
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [patch 2/4] Update for changes in mieq API

[Peter Hutterer]

On Mon, Sep 29, 2008 at 11:01:43PM +0100, [EMAIL PROTECTED] wrote:
> @@ -221,19 +220,21 @@ winMouseWheel (ScreenPtr pScreen, int iD
>  void
>  winMouseButtonsSendEvent (int iEventType, int iButton)
>  {
> -  xEvent xCurrentEvent;
> +  EventList *events = InitEventList(GetMaximumEventsNum());
> +  int i, nevents;



InitEventList should only be called once and that's done in the DIX anyway.
Use GetEventList() instead here.

> +  nevents = GetPointerEvents(events, inputInfo.pointer, iEventType, iButton,
> +  POINTER_RELATIVE, 0, 0, NULL);

No, you can't do that. Calling GPE for the VCP probably won't work correctly
(at least not in all cases). You need a slave device that generates the
events, and it must be attached to the VCP.

> +/**
> + * Enqueue a motion event.
> + *
> + *  XXX: miPointerMove does exactly this, but is static :-( (and uses a 
> static buffer)
> + *
> + */
> +void winEnqueueMotion(int x, int y)

I don't think this one is needed. use miPointerSetPosition instead.

> Index: xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmultiwindowwndproc.c
> +++ xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> @@ -535,9 +535,9 @@ winTopLevelWindowProc (HWND hwnd, UINT m
>   }
>  
>/* Deliver absolute cursor position to X Server */
> -  miPointerAbsoluteCursor (ptMouse.x - s_pScreenInfo->dwXOffset,
> -ptMouse.y - s_pScreenInfo->dwYOffset,
> -g_c32LastInputEventTime = GetTickCount ());
> +  winEnqueueMotion(ptMouse.x - s_pScreenInfo->dwXOffset, 
> +ptMouse.y - s_pScreenInfo->dwYOffset);
> +

as above, miPointerSetPosition.
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Sep 30, 2008 at 02:15:45PM +0200, Søren Hauberg wrote:
> 2008/9/29 Peter Hutterer <[EMAIL PROTECTED]>:
> > evdev already has the code for device properties in e.g. draglock.c. Best to
> > just check it but maybe wait a day or so, I have changes in the pipe that
> > restructure the use of DP in evdev. The API is the same, but the handler
> > registration is a bit different.
> 
> So, I'm looking into this code at the moment. First question: does
> this require an X server from git? 

yes, the current property code was only merged a few days ago.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Sep 30, 2008 at 11:53:44AM +0200, Søren Hauberg wrote:
> Okay, so I'm attaching my latest patch. This should handle everything
> except setting/getting calibration parameters. I'll look into this
> after lunch today. I'd love some feedback on the patch, as I think
> this is the best structure, but since I'm a newbie I just might be
> mistaken.


+/* Touch screen parameters */
+struct {
+BOOLflip_x;
+BOOLflip_y;
+BOOLswap_xy; /* Some devices send (y, x) instead of 
(x, y). Currently not used */
+int min_x;
+int max_x;
+int min_y;
+int max_y;
+} touchscreen;

the last four fields are redundant, since the EvdevRec already has those.
flip_x/y should also be moved into the EvdevRec, as it allows other devices to
benefit from it. For relative devices flip would be simply inverted. For
absolute ones - you can do the inversion before the call to
xf86PostMotionEvent. 
On that note - please replace "flip_x" with "invert_x" etc. Flip is
ambiguous.

regarding swap_x/y:
do i read that right that these devices advertise x/y but then send y/x
coordinates? 

So the kernel driver says that X, Y have ranges of - say - [0, 1000], [-1000,
0], the actual coordinates come through as -500, 500?
If this is the case, please fix the kernel driver, I don't really like the
current solution.

+
+if (pEvdev->flags & EVDEV_TOUCHSCREEN)
+EvdevInitTouchscreen(pInfo);

I trust that'll disappear from the final patch.

So, summary:
- we separate the invert_x/y part into a separate patch, plus the code needed
  for relative devices.
- we ignore the swap x/y crazyness for now.
- we can ditch hunks 2 and 7 from the evdev.c patch.

I like it.

and by "we" I mean of course "you" ;)
since you're the one with the device, please focus on the last two of the
three points. axis inversion can be added easily lateron by anyone with axes
to exotic devices such as mice or touchpads.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Sep 30, 2008 at 03:14:17PM +0200, Søren Hauberg wrote:
> My impression is that the ones in EvdevRec means something different.
> The ones in the 'touchscreen' struct are the calibration parameters.
> 'min_x' is the smallest x value that the hardware actually sends, and
> similar for the other fields. So, I get x values in the range
> 
>   [EvdevRec.touchscreen.min_x, EvdevRec.touchscreen.max_x]
> 
> and I need to transform these linearly into the range
> 
>   [EvdevRec.min_x, EvdevRec.max_x]

min/max is read from the kernel at startup. So you mean there's a difference
in the axis range the kernel reports and the actual value range in the events?
Does the kernel report axis ranges at all?

> So, yes, you understand correctly. From what I understand, some
> devices (including mine) does this, and there is no way for the kernel
> to detect it (this is my understanding, it might not be the truth).
> Currently, the 'usbtouchscreen' kernel module has a parameter
> 'swap_xy' that makes the swap, but from what I understand, the kernel
> developers are likely to remove this in the future, since it won't
> work when you have multiple touch screens attached. I doubt we'll see
> it fixed in the kernel (I don't know how to do it), which is why I
> wanted the parameter in this driver. I can remove it if you don't want
> it, but I think it's needed.

hmm. leave it out for now and let's focus on getting the touchscreen support.
we can put quirks like this in later, as a separate patch.

> 
> > +
> > +if (pEvdev->flags & EVDEV_TOUCHSCREEN)
> > +EvdevInitTouchscreen(pInfo);
> >
> > I trust that'll disappear from the final patch.
> 
> Why? (remember, I'm an X-newbie) I need to initialize the device to
> get parameters. How would you like me to do this?

all the parameters in InitTouchscreen were hardcoded. Just move what you have
to into EvdevPreInit (but with the invert and swap culling there is only
min/max left anyway). Get it from the options there (xf86SetIntOption(...) for
example).

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: .pc files for input drivers

[Peter Hutterer]

On Tue, Sep 30, 2008 at 10:54:51AM -0700, Donnie Berkholz wrote:
> > Anyone opposed to a follow-up patch to install the .pc file?
> > If not, xorg-.pc or just.pc?
> 
> If this is going in every driver, would it make sense as part of 
> xorg-macros?  Also I'm wondering whether the sdk dir should be detected from
> xorg-server instead of having a configure flag at all.

Amended patch below. Turns out the sdk detection was already there anyway, so
this patch is shorter than the previous one. 
And makes the need for macros unnecessary, since it's only one line in
configure.ac and all drivers that matter already get the sdkdir anyway. 

>From 95a970ed66184aff5b89434e00ca8c012c54d377 Mon Sep 17 00:00:00 2001
From: Peter Hutterer <[EMAIL PROTECTED]>
Date: Fri, 26 Sep 2008 10:42:05 +0930
Subject: [PATCH] Install xorg-evdev.pc for clients who need evdev-properties.h

---
 .gitignore  |1 +
 Makefile.am |7 +--
 configure.ac|7 ++-
 include/Makefile.am |2 ++
 xorg-evdev.pc.in|7 +++
 5 files changed, 21 insertions(+), 3 deletions(-)
 create mode 100644 include/Makefile.am
 create mode 100644 xorg-evdev.pc.in

diff --git a/.gitignore b/.gitignore
index 38eebd9..78a4243 100644
--- a/.gitignore
+++ b/.gitignore
@@ -24,3 +24,4 @@ missing
 stamp-h1
 *.bz2
 *.gz
+*.pc
diff --git a/Makefile.am b/Makefile.am
index 11064e0..140aab1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,9 +19,12 @@
 #  CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 
 AUTOMAKE_OPTIONS = foreign
-SUBDIRS = src man
+SUBDIRS = src man include
 
-EXTRA_DIST = ChangeLog autogen.sh
+pkgconfigdir = $(libdir)/pkgconfig
+pkgconfig_DATA = xorg-evdev.pc
+
+EXTRA_DIST = ChangeLog autogen.sh xorg-evdev.pc.in
 
 MAINTAINERCLEANFILES=ChangeLog
 
diff --git a/configure.ac b/configure.ac
index 5a29874..72e6df7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -58,6 +58,7 @@ XORG_DRIVER_CHECK_EXT(XINPUT, inputproto)
 # Checks for pkg-config packages
 PKG_CHECK_MODULES(XORG, xorg-server xproto $REQUIRED_MODULES)
 sdkdir=$(pkg-config --variable=sdkdir xorg-server)
+AC_SUBST(sdkdir)
 
 CFLAGS="$CFLAGS $XORG_CFLAGS "' -I$(top_srcdir)/src'
 AC_SUBST([CFLAGS])
@@ -70,4 +71,8 @@ AC_HEADER_STDC
 XORG_MANPAGE_SECTIONS
 XORG_RELEASE_VERSION
 
-AC_OUTPUT([Makefile src/Makefile man/Makefile])
+AC_OUTPUT([Makefile
+   src/Makefile
+   man/Makefile
+   include/Makefile
+   xorg-evdev.pc])
diff --git a/include/Makefile.am b/include/Makefile.am
new file mode 100644
index 000..58d7c39
--- /dev/null
+++ b/include/Makefile.am
@@ -0,0 +1,2 @@
+EXTRA_DIST = evdev-properties.h
+sdk_HEADERS = evdev-properties.h
diff --git a/xorg-evdev.pc.in b/xorg-evdev.pc.in
new file mode 100644
index 000..f85423f
--- /dev/null
+++ b/xorg-evdev.pc.in
@@ -0,0 +1,7 @@
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
+
+Name: xorg-evdev
+Description: X.Org evdev input driver.
+Version: @PACKAGE_VERSION@
+Cflags: -I${includedir}
-- 
1.5.4.3


___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: .pc files for input drivers

[Peter Hutterer]

On Tue, Sep 30, 2008 at 08:04:50PM -0700, Dan Nicholson wrote:
> Total nitpicking, but it's not necessary to add xorg-evdev.pc.in to
> EXTRA_DIST since you added it to AC_OUTPUT in configure.ac. automake
> takes into account files necessary for autoconf and adds them to
> DIST_COMMON.

Nitpicking is good. Thanks, I removed it.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Sep 30, 2008 at 04:56:57PM +0200, Søren Hauberg wrote:
> Okay, here's my latest attempt at a patch. I've renamed "flip_[x|y]"
> to "invert_[x|y]" and moved them into "EvdevRec", I've removed
> "swap_xy", and I've moved the reading of parameters to PreInit.
> 
> I hope that's what you wanted. If not let me know. I'm hoping to have
> access to the touch screen for an hour or two on friday, so I can do a
> bit more testing/development at that time.

Ok, I took your patches, split them up and fiddled with them a bit.

0004-Add-support-for-axis-inversion.patch
  - self-explanatory, works well btw, at least for relative devices.

0005-Allow-specification-of-Min-Max-for-x-y-overriding-t.patch
  - take config options MinX/MaxX/etc. if given. They override the
auto-detected values from xorg.conf

0006-Add-touchscreen-support.patch
  - this is the core of your patch, the touchscreen support for BTN_TOUCH.

I got a patch for property support for axis inversion on top of those done as
well.
If we get property support for min/max x and update the ValuatorClassRec
accordingly (I need to find a method to do that without upsetting the server
and all client) then we can do the calibration on-the-fly.
Alternatively, if we find we can't touch the VCR, xf86ScaleAxis should do the
job (that's instead of your TRANFORM macro).

Cheers,
  Peter
>From 23c90251b920e95baaf1755243282f7fcda2d231 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?S=C3=B8ren=20Hauberg?= <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 11:07:57 +0930
Subject: [PATCH] Add support for axis inversion.

---
 src/evdev.c |   21 ++---
 src/evdev.h |2 ++
 2 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index b678a0e..c5fd7d5 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -348,8 +348,13 @@ EvdevReadInput(InputInfoPtr pInfo)
 	}
 }
 
-if (dx != 0 || dy != 0)
+if (dx != 0 || dy != 0) {
+if (pEvdev->invert_x)
+dx *= -1;
+if (pEvdev->invert_y)
+dy *= -1;
 xf86PostMotionEvent(pInfo->dev, FALSE, 0, 2, dx, dy);
+}
 
 /*
  * Some devices only generate valid abs coords when BTN_DIGI is
@@ -361,8 +366,15 @@ EvdevReadInput(InputInfoPtr pInfo)
  * just works.
  */
 if (abs && pEvdev->tool) {
-	xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2,
-			pEvdev->abs_x, pEvdev->abs_y);
+int abs_x, abs_y;
+abs_x = pEvdev->abs_x;
+abs_y = pEvdev->abs_y;
+if (pEvdev->invert_x)
+abs_x = pEvdev->max_x - abs_x;
+if (pEvdev->invert_y)
+abs_y = pEvdev->max_y - abs_y;
+
+	xf86PostMotionEvent(pInfo->dev, TRUE, 0, 2, abs_x, abs_y);
 }
 }
 
@@ -1335,6 +1347,9 @@ EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
 pEvdev->noXkb = noXkbExtension;
 /* parse the XKB options during kbd setup */
 
+pEvdev->invert_x = xf86SetBoolOption(pInfo->options, "InvertX", FALSE);
+pEvdev->invert_y = xf86SetBoolOption(pInfo->options, "InvertY", FALSE);
+
 if (EvdevProbe(pInfo)) {
 	close(pInfo->fd);
 	xf86DeleteInput(pInfo, 0);
diff --git a/src/evdev.h b/src/evdev.h
index c145fbc..525acb1 100644
--- a/src/evdev.h
+++ b/src/evdev.h
@@ -65,6 +65,8 @@ typedef struct {
 int flags;
 int tool;
 int buttons;/* number of buttons */
+BOOL invert_x;
+BOOL invert_y;
 
 /* XKB stuff has to be per-device rather than per-driver */
 int noXkb;
-- 
1.5.4.3

>From 54abde575e180f0581d14937eb20ea06d8a4fd1a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?S=C3=B8ren=20Hauberg?= <[EMAIL PROTECTED]>
Date: Wed, 1 Oct 2008 11:53:20 +0930
Subject: [PATCH] Allow specification of Min/Max for x/y, overriding the auto-detected values.

---
 src/evdev.c |   17 +
 1 files changed, 13 insertions(+), 4 deletions(-)

diff --git a/src/evdev.c b/src/evdev.c
index c5fd7d5..48cf1b0 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -776,10 +776,14 @@ EvdevAddAbsClass(DeviceIntPtr device)
 	return !Success;
 }
 
-pEvdev->min_x = absinfo_x.minimum;
-pEvdev->max_x = absinfo_x.maximum;
-pEvdev->min_y = absinfo_y.minimum;
-pEvdev->max_y = absinfo_y.maximum;
+if (pEvdev->min_x == -1)
+pEvdev->min_x = absinfo_x.minimum;
+if (pEvdev->max_x == -1)
+pEvdev->max_x = absinfo_x.maximum;
+if (pEvdev->min_y == -1)
+pEvdev->min_y = absinfo_y.minimum;
+if (pEvdev->max_y == -1)
+pEvdev->max_y = absinfo_y.maximum;
 
 if (!InitValuatorClassDeviceStruct(device, 2,
 #if GET_ABI_MAJOR(ABI_XINPUT_VERSION) < 3
@@ -1350,6 +1354,11 @@ EvdevPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
 pEvdev->invert_x = xf86SetBoolOption(pInfo->options, "InvertX", FALSE);
 pEvdev->invert_y = xf86SetBoolOption(pInfo->options, "InvertY", FALSE);
 
+pEvdev->min_x = xf86SetIntOption(pInfo->options, "MinX", -1);
+pEvdev->max_x = xf86SetIntOption(pInfo->options, "MaxX", -1);
+pEvdev->min_y = xf86SetIntOption(pInfo->options, "MinY",

Re: Does touchpads have buttons?

[Peter Hutterer]

On Wed, Oct 01, 2008 at 12:21:06AM +0200, Simon Thum wrote:
> typedef struct _AbsoluteClassRec {
> /* Calibration. */
> int min_x;
> int max_x;
> int min_y;
> int max_y;
> int flip_x;
> int flip_y;
> int   rotation;
> int button_threshold;
>
> /* Area. */
> int offset_x;
> int offset_y;
> int width;
> int height;
> int screen;
> XID   following;
> } , *AbsoluteClassPtr;
>
> All that crap gets initialized, copied, whatever, it's just not made use  
> of. This led me to give Soeren the bogus advice so use it, but it seems  
> not really possible. What's the state of this Xinput part? Deprecated or  
> incomplete?

>From a quick grep in the xserver tree, all this is essentially for the
DeviceControl interface and changes to the above are supposed to be passed to
the driver that then does stuff.

The devicecontrol interface is being replaced by properties, so assume it as
deprecated. 

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-mutouch 1.2.1

[Peter Hutterer]

mutouch 1.2.0 has issues with the current X server as it does not handle
inverted axes (or handles them as inverted even when they aren't). This is
fixed now, and I have anecdotal evidence that it even works.

Peter Hutterer (6):
  Check for XINPUT ABI 3.
  Remove trailing whitespaces.
  Handle axis inversion in the driver.
  Fix stupid typos from last patch.
  Remove pre-XFREE86_V4 cruft.
  mutouch 1.2.1

git tag: xf86-input-mutouch-1.2.1

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.2.1.tar.bz2
MD5: f28998cdfae2a4c41589299a4ee1f459  xf86-input-mutouch-1.2.1.tar.bz2
SHA1: c5883c2c5cc80186f711751e8847c9c07f2e4448  xf86-input-mutouch-1.2.1.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-mutouch-1.2.1.tar.gz
MD5: d2690ccc09b86e81eaaeb5aa522fe8e0  xf86-input-mutouch-1.2.1.tar.gz
SHA1: 528fa6d5b33fecfbc6ac0809601ae20fa7b1f302  xf86-input-mutouch-1.2.1.tar.gz



signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-evdev 2.0.6

[Peter Hutterer]

Fix for Launchpad bug 276887: the X server still receives events even even
when VT-switched away. These events are then partially replayed on the
currently focused client when re-entering the VT.

Thanks to bryce and mjg59 for their help fixing this.



Peter Hutterer (2):
  Close fd on DEVICE_OFF. (LP #276887)
  evdev 2.0.6

git tag: xf86-input-evdev-2.0.6

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.6.tar.bz2
MD5: 499abf720b8c8ab0be1f3c0c62b2a399  xf86-input-evdev-2.0.6.tar.bz2
SHA1: fb84b919f2852fc345e62f7e17a209957e1304bc  xf86-input-evdev-2.0.6.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.6.tar.gz
MD5: 2f0ffbbe40418a615c80ba39da7da666  xf86-input-evdev-2.0.6.tar.gz
SHA1: 39ec8a73a00b73542862b1ade4cc53a0fe2e3201  xf86-input-evdev-2.0.6.tar.gz



signature.asc
Description: Digital signature
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics and the scroll zone after resume from suspend.

[Peter Hutterer]

On Thu, Oct 02, 2008 at 10:12:40AM +0100, Colin Guthrie wrote:
> I'm using xf86-input-synaptics-0.15.2 and wonder if other users have a 
> problem with the scroll zone after resuming from suspend.
> 
> For me it just stops working which is pretty annoying. Does anyone know 
> how to help diagnose and/or fix?

Do you have the device configured in your xorg.conf?
If so, check the log, it might not come back properly after resume and the
device is added through HAL instead. In this case, the options specified in
the fdi file are the ones used, not the ones in the xorg.conf.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Software for calibrating a touch screen

[Peter Hutterer]

On Wed, Oct 01, 2008 at 11:45:03AM +0200, Søren Hauberg wrote:
> Good point. Perhaps the recently added 'invert_[x|y]' options in the
> evdev driver should be removed? Perhaps not, as such an option might
> be generally usable.

I think it is a feature worth having. The cost of maintainance is low enough
to not worry about it, even if it is used little.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Virtual core keyboard

[Peter Hutterer]

On Tue, Sep 30, 2008 at 02:44:26PM +0100, John Tapsell wrote:
>   I have a device without a keyboard, but I still send keyboard events
> to X.  Specifically I use synergy.

what version of X are you running?

> Is there a way to add some sort of 'virtual' keyboard?

X server 1.4 and above always have a virtual keyboard, it's hardcoded in the
startup procedure and cannot be removed. Last I checked synergy was still
working but that's a few months ago now. Unless we broke it since, it could be
a problem with your setup.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Synaptics and the scroll zone after resume from suspend.

[Peter Hutterer]

On Thu, Oct 02, 2008 at 12:44:29PM +0100, Colin Guthrie wrote:
> Now what to do I wonder... as /dev/input/event2 does actually exist.. I 
> wonder if it's a timing thing?

It probably is. I don't know how to get around that though other than adding
the synaptics options to your fdi file and letting HAL do the job.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Xlib: extension "Generic Event Extension" missing on display ":0.0".

[Peter Hutterer]

On Thu, Oct 02, 2008 at 07:35:10AM -0700, Yan Seiner wrote:
> >> Xlib:  extension "Generic Event Extension" missing on display ":0.0".
 
> (Unless I don't know enough to know better.  Should I be concerned about 
> this?)

No, and I've been meaning to silence this warning anyway. 

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] RFC: remove repeater functionality from xf86-input-synaptics

[Peter Hutterer]

Thanks, applied and pushed.

I added a man-page fix to this patch as well so the removal is documented.

Cheers,
  Peter

On Thu, Oct 02, 2008 at 03:00:39PM +0100, Magnus Kessler wrote:
> I would like to propose to remove the repeater functionality completely from 
> the synaptics touchpad driver. It is buggy in its current implementation 
> and its usefulness is questionable.
> 
> According to the INSTALL file, the repeater is there only for testing. In 
> fact, if a supported device is found even a configured repeater fifo is 
> automatically disabled. For most users the functionality is therefore 
> irrelevant and can be confusing. If I understand the workings of the 
> repeater correctly, a developer could instead just read the data directly 
> from an unsupported device's character special file under /dev 
> or /dev/input.
> 
> With today's more dynamic device configuration possibilities via udev and 
> hal it's also less likely that the synaptics driver would silently block 
> another devices data, this situation being for what the repeater 
> functionality seems to have been introduced in the past.
> 
> Please review the attached patch and apply if appropriate.
> 
> Best Regards,
> 
> Magnus Kessler
> 
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Poll: Should Xorg change from using Ctrl+Alt+Backspace to something harder for users to press by accident?

[Peter Hutterer]

On Fri, Oct 03, 2008 at 02:55:00AM +0200, [EMAIL PROTECTED] wrote:
> On Tue, Sep 23, 2008 at 01:52:53PM +0930, Peter Hutterer wrote:
> > driver kbd: hardcodes Ctrl + Alt + Backspace. (IMHO that's a bug anyway)
> > driver evdev: the XKB map decides what happens.
> 
> I don't know whether this is really related (I'm pretty sure I
> experienced that with kbd driver as well), but the fact that zap depends
> on xkb is actually quite problematic: When the xkb map is somehow
> borked, the server still starts, but it's not possible to zap (nor to
> switch console)... This gets really ugly when no other means to exit the
> server is available :-)

You're saying a broken installation causes certain features to not work? :)

If the xkb map is broken that usually means the server has a bug (->
bugs.fdo.org) or xkeyboard-config is wrongly installed -> install it correctly
(from git).

with either a released server and even git master there's no reason why the
xkbmap should be busted.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH 2/4] X event queue mutex

[Peter Hutterer]

On Tue, Oct 07, 2008 at 01:46:21AM -0300, Tiago Vignatti wrote:
> A problem that I see is in GetPointerEvents() function. It's bloated and 
> confusing. It generates X events and also updates the cursor on screen. 
> We don't need to mix this two actions in one function. For instance, I 
> did a quickly hack here calling miPointerSetPosition() directly from 
> evdev driver (!) instead inside GPE and apparently all worked nice. So 
> if we could only put in a separate thread the pieces that deal with 
> cursor's update and not related with X events then we'd be winning -- I 
> failed to not see this before  :(

The actual event generation is the least of your worries here.

GPE basically does:
1. sanity checking
2. get the MD, update the SD from the MD if we switched devices so we can
   apply the new coordinates.
3. accelerate motion and/or clip axes as applicable.
4. scale to screen, write it into the MD
5. NOW you have your coordinates you can move to
6. do event-specific stuff you don't have to worry about for displaying the
   cursor.

You can't easily get around 1-4 since you won't know the position otherwise.
I'm pretty sure 6 is negligable for processing time since all we're basically
doing there is assigning values to already allocated memory.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Oct 07, 2008 at 11:26:50AM +0200, Søren Hauberg wrote:
> 2008/10/1 Peter Hutterer <[EMAIL PROTECTED]>:
> > Ok, I took your patches, split them up and fiddled with them a bit.
> 
> [snip]
> 
> > 0005-Allow-specification-of-Min-Max-for-x-y-overriding-t.patch
> >  - take config options MinX/MaxX/etc. if given. They override the
> >auto-detected values from xorg.conf
> >
> > 0006-Add-touchscreen-support.patch
> >  - this is the core of your patch, the touchscreen support for BTN_TOUCH.
> 
> Did you actually apply these two patches? They don't appear when I
> checkout git, but perhaps I'm looking at the wrong branch or
> something.

no, not yet. You said you're going to get some more face-time with the
touchscreen so I was hoping you'd give me some testing feedback.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

The current code exposes to inconsistent updates, i.e. if handler N succeeds
but handler N+1 fails in setting the property, an error is returned to the
client although parts of the server now behave as if the property change
succeeded.

This patch adds a "checkonly" parameter to the SetProperty handler. The
handlers are then called twice, once with checkonly set to TRUE.
On the checkonly run, handlers _MUST_ return error codes if the property
cannot be applied. Handlers are not permitted to actually apply the changes.
On the second run, handlers are permitted to apply property changes.
Errors codes returned on the second run are ignored.
---
 Xi/xiproperty.c|   34 ++
 dix/devices.c  |   14 +-
 include/exevents.h |3 ++-
 include/inputstr.h |3 ++-
 4 files changed, 35 insertions(+), 19 deletions(-)

diff --git a/Xi/xiproperty.c b/Xi/xiproperty.c
index 1e4ed46..2ff5cae 100644
--- a/Xi/xiproperty.c
+++ b/Xi/xiproperty.c
@@ -97,7 +97,8 @@ long
 XIRegisterPropertyHandler(DeviceIntPtr dev,
   int (*SetProperty) (DeviceIntPtr dev,
   Atom property,
-  XIPropertyValuePtr prop),
+  XIPropertyValuePtr prop,
+  BOOL checkonly),
   int (*GetProperty) (DeviceIntPtr dev,
   Atom property),
   int (*DeleteProperty) (DeviceIntPtr dev,
@@ -346,22 +347,31 @@ XIChangeDeviceProperty (DeviceIntPtr dev, Atom property, 
Atom type,
 
 if (dev->properties.handlers)
 {
-XIPropertyHandlerPtr handler = dev->properties.handlers;
-while(handler)
+XIPropertyHandlerPtr handler;
+BOOL checkonly = TRUE;
+/* run through all handlers with checkonly TRUE, then again with
+ * checkonly FALSE. Handlers MUST return error codes on the
+ * checkonly run, errors on the second run are ignored */
+do
 {
-if (handler->SetProperty)
+handler = dev->properties.handlers;
+while(handler)
 {
-rc = handler->SetProperty(dev, prop->propertyName,
-  &new_value);
-if (rc != Success)
+if (handler->SetProperty)
 {
-if (new_value.data)
-xfree (new_value.data);
-return (rc);
+rc = handler->SetProperty(dev, prop->propertyName,
+&new_value, checkonly);
+if (checkonly && rc != Success)
+{
+if (new_value.data)
+xfree (new_value.data);
+return (rc);
+}
 }
+handler = handler->next;
 }
-handler = handler->next;
-}
+checkonly = !checkonly;
+} while (!checkonly);
 }
 if (prop_value->data)
 xfree (prop_value->data);
diff --git a/dix/devices.c b/dix/devices.c
index 9d4ce34..f5a3e99 100644
--- a/dix/devices.c
+++ b/dix/devices.c
@@ -103,17 +103,21 @@ DevPrivateKey UnusedClassesPrivateKey = 
&UnusedClassesPrivateKeyIndex;
  * DIX property handler.
  */
 static int
-DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
+DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
+  BOOL checkonly)
 {
 if (property == XIGetKnownProperty(XI_PROP_ENABLED))
 {
 if (prop->format != 8 || prop->type != XA_INTEGER || prop->size != 1)
 return BadValue;
 
-if ((*((CARD8*)prop->data)) && !dev->enabled)
-EnableDevice(dev);
-else if (!(*((CARD8*)prop->data)) && dev->enabled)
-DisableDevice(dev);
+if (!checkonly)
+{
+if ((*((CARD8*)prop->data)) && !dev->enabled)
+EnableDevice(dev);
+else if (!(*((CARD8*)prop->data)) && dev->enabled)
+DisableDevice(dev);
+}
 }
 
 return Success;
diff --git a/include/exevents.h b/include/exevents.h
index 4df0aee..667004a 100644
--- a/include/exevents.h
+++ b/include/exevents.h
@@ -232,7 +232,8 @@ extern long XIRegisterPropertyHandler(
 DeviceIntPtr dev,
 int (*SetProperty) (DeviceIntPtr dev,
 Atom property,
-XIPropertyValuePtr prop),
+XIPropertyValuePtr prop,
+BOOL checkonly),
 int (*GetProperty) (DeviceIntPtr dev,
  

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Wed, Oct 08, 2008 at 08:11:26AM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > The current code exposes to inconsistent updates, i.e. if handler N succeeds
> > but handler N+1 fails in setting the property, an error is returned to the
> > client although parts of the server now behave as if the property change
> > succeeded.
> I understand the problem, but are there really uses for this? I mean, 2
> handlers responding to the same prop is nothing I could make sense of.
> At most, an additional handler which 'watches' the prop this way is
> conceivable to me.

Axis range changes are one example I can think of. The driver needs to update
it for axis inversion, the server for scaling.

> > This patch adds a "checkonly" parameter to the SetProperty handler. The
> > handlers are then called twice, once with checkonly set to TRUE.
> > On the checkonly run, handlers _MUST_ return error codes if the property
> > cannot be applied. Handlers are not permitted to actually apply the changes.
> > On the second run, handlers are permitted to apply property changes.
> > Errors codes returned on the second run are ignored.
> Things could be simpler IMO when having different return codes for 'I
> don't care' vs. 'Yep, property properly changed'. I think that's the
> root of the problem.

No, this doesn't help if handler 1 reports "properly changed" and handler 2
reports a BadValue (for whatever reason).
Since the property handlers don't change the actual property value (that's
done in the server on Success), "Don't care" is essentially the same as
"properly changed" to the server.
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: Does touchpads have buttons?

[Peter Hutterer]

On Tue, Oct 07, 2008 at 11:48:14PM +0200, Søren Hauberg wrote:
> Okay, just wasn't sure if I missed anything. I had a little time to
> test today, and things didn't work that well for me. I tried using the
> parameters (min_x, max_x, ...) that worked with my original patches,
> and evtouch, and they did not provide a good calibration. I wasn't
> able to track down the problem, so I don't really know what to report.
> I'm guessing that the problem is that both evtouch and my suggested
> changes scaled the output to [0, 1023] x [0, 1023], which isn't what
> happens in the current code path. 

Right, there is one piece missing from the current code path and that's the
double-scaling.
Your code scaled from device->min/max and then let the server scale to
whatever the axes were set up. This part is missing, assuming that the
correct min/max is defined at startup already.

I'd like to avoid the double-scaling, but i'm not 100% sure on how to do it
yet.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Wed, Oct 08, 2008 at 09:12:44AM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > Axis range changes are one example I can think of. The driver needs to 
> > update
> > it for axis inversion, the server for scaling.
> Hmm - that essentially forbids moving inversion into the server (which
> could be done), because we'd never know if the driver wouldn't also do
> it.

Not necessarily. Once the server has support for X, we can just remove it from
the driver and say that you need at least server Y with this driver version.
Or, once the server has a "XYZ" property, you can just make e.g. "Evdev XYZ"
an alias for "XYZ", keeping backwards compat with clients.
 
> > No, this doesn't help if handler 1 reports "properly changed" and handler 2
> > reports a BadValue (for whatever reason).
> Yep, that's why it would need to be complemented with a
> only-one-non-ignoring-handler policy. This would foster clear separation
> and shouldn't be problematic to introduce in the early stages.

right. but then you'd need a method to figure out whether your handler is the
one that is allowed to return an error code. Alternatively, the server could
just stop processing handlers after the first "active" handler. In which case
you can have a driver that needs to access a property but is never called.
Both cases are not quite optimal.

> > Since the property handlers don't change the actual property value (that's
> > done in the server on Success), "Don't care" is essentially the same as
> > "properly changed" to the server.
> Yes, but the actual propery value may not be what reflects the state in
> the server, e.g. as in the 'Enabled' prop. So there is a difference.

if a property does not reflect the state as it is in the server, I'd consider
this a bug. Regarding the example: the "enabled" prop actually calls
Enable/DisableDevice, so it should always be the server state.

> Not that your design is bad - I just think we should keep complexity out
> of handlers. They're what's going to multiply. 2-phase is good in
> general, but IMO overkill.

I don't quite see the overkill there. All the evdev code looks basically

if (values_are_bananas)
   return BadSomething;

if (!checkonly) { // this line got added
  foo();
}

I can't imagine it being much simpler than that.

> PS: Thanks for attributing the scaling stuff to me, but that really
> hadn't been necessary.

This way git-blame points at you if it breaks :)
I think I just ammended from the rounding patch you sent, never bothered to
change the author.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Wed, Oct 08, 2008 at 11:05:07PM +0200, Simon Thum wrote:
> > Not necessarily. Once the server has support for X, we can just remove it 
> > from
> > the driver and say that you need at least server Y with this driver version.
> > Or, once the server has a "XYZ" property, you can just make e.g. "Evdev XYZ"
> > an alias for "XYZ", keeping backwards compat with clients.
> We're arguing in different directions here. My point is, that this all
> is superfluous if you avoid double-defined props in the first place.
> Enforcing that somewhat helps to resist the temptation :)

So your point is to never have properties in the driver that could be in the
server? This may be tough, as drivers have a quicker turnover time, and
features can get added easier.

> The question is whether one needs it. Your last major change was all
> about reducing complexity. You could go further in that direction by
> adopting only-one-non-ignoring-handler - at the expense of not
> supporting some (IMO questionable) useages.

I agree with the example being of questionable use. However, as we just
started with the whole thing I don't think we can quite grasp what the next
few months may bring in terms of property support. And I wouldn't be surprised
if a use-case pops up where we need that.

One other example I came up with while writing the email: some property
that needs handling in the DIX and one of the DDXes. This would require two
separate handlers, the code can't be merged into one.

> > if a property does not reflect the state as it is in the server, I'd 
> > consider
> > this a bug. Regarding the example: the "enabled" prop actually calls
> > Enable/DisableDevice, so it should always be the server state.
> Sure, we can reasonably assume that. The mere point is the the state is
> not determined by the prop, just reflected (e.g. someone else could call
> EnableDevice, like VTSwitch or power mgmt). This small difference is
> what I'd say makes for a difference in return codes. (Plus, pretty
> unrelated: your only chance of knowing is having a getter).

So the theory is that whatever changes state in the server _MUST_ also update
the respective property. In the given example, not updating the property is
akin to not setting device->enabled = FALSE when disabling the device.
If the state is changed through changing the property - easy. Otherwise, the
code must ensure that XIChangeDeviceProperty() is called.

> Overkill was mainly referring to the possibilities it opens (n-times
> handled props) and the associated complexity, which would inevitably
> affect property users (like you and me).
 
There's two types of users: clients and server/driver developers. For clients
the handlers are invisible anyway, and either it succeeds or it doesn't - in
which case we get an error value. And I hope that any property is reasonably
documented so that one knows what values are legit :)

Developers, well, I still think that there is little complexity. 
Register a handler, check only on the first call, change state on the second
call. We don't have to coordinate with other handlers, the second run simply
never starts if another handler disagrees.

Sure, it may get complicated if we have 10 handlers for each property. But at
that point we should got back to the drawing board and see what we have done
wrong. Because I don't think that merging the code from 10 different handlers
into one handler would be any more straightforward.

> So, I pushed that far enough - it is your decision, and I can live with
> whatever you end up with.

My current decision is to use the checkonly flag. It comes at the cost of a
single parameter and an if condition for each property. Not using it comes at
the cost of maybe needing to break the ABI later, when it may already be too
late (ABI freeze, and whatnot).

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Thu, Oct 09, 2008 at 03:20:36AM +0200, Simon Thum wrote:
> > So your point is to never have properties in the driver that could be in the
> > server? This may be tough, as drivers have a quicker turnover time, and
> > features can get added easier.
> Well, against double-handling a prop in general. Uh, I didn't even rant
> about order dependencies which may sneak in.

doh. yes, those would be an issue.
 
> Alternative (assuming only-one-handler): Should anyone 'capture' an
> existing prop we could add some controlled pass-through behaviour, e.g.
> by starting the handler list from the current (or any specified) handler on.

I'm not sure I understand what you mean here.
 
> > If the state is changed through changing the property - easy. Otherwise, the
> > code must ensure that XIChangeDeviceProperty() is called.
> Then you really should be looking at VTSwitch or power mgmt.
> That part is clear, but it's so easy to circumvent unexpectedly. But I
> don't know anything reliable either.

ok, I'll check that and make sure it isn't broken.

> > which case we get an error value. And I hope that any property is reasonably
> > documented so that one knows what values are legit :)
> Do you intend to have some point to collect related info? E.g. wiki? It
> could help a lot to easily see what types there are, how others did etc.

right now, the properties are documented in the header files that define their
names. They should eventually be added to the man pages, once they settle down
a bit.
 
> > Sure, it may get complicated if we have 10 handlers for each property. But 
> > at
> > that point we should got back to the drawing board and see what we have done
> > wrong. Because I don't think that merging the code from 10 different 
> > handlers
> > into one handler would be any more straightforward.
> Sorry, but I can't help regarding that as an argument against multiple
> handlers per prop - but anyway.

So based on the current implementation (the one that is in master), what's
your concrete proposal then? Just leave it an beat up anyone trying to
double-handle a property? Not that I would be opposed to that, but it's likely
going to be me who's going to be beaten up :)
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XTerm exits immediatly with self-compiled xorg

[Peter Hutterer]

On Wed, Oct 08, 2008 at 06:59:33PM +0200, Clemens Eisserer wrote:
> The XKEYBOARD keymap compiler (xkbcomp) reports:^M
> > Warning:  Type "ONE_LEVEL" has 1 levels, but  has 2 symbols^M
> >   Ignoring extra symbols^M
> Errors from xkbcomp are not fatal to the X server^M

You can ignore this warning, it is xkbcomp telling you that a key has more
symbols than it should have. Nothing to see here, please move along.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: xserver: Branch 'master'

[Peter Hutterer]

Apologies for not spotting this earlier.

On Mon, Sep 08, 2008 at 08:51:56AM -0700, Aaron Plattner wrote:
> commit 079625570d51e41569b73b2fd9237eb8f967f408
> Author: Aaron Plattner <[EMAIL PROTECTED]>
> Date:   Mon Sep 8 08:50:52 2008 -0700
> 
> Bump ABI major versions for the TryClientExceptions change from commit 
> 883811c.


> 
>  #define ABI_ANSIC_VERSIONSET_ABI_VERSION(0, 4)
> -#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(4, 1)
> -#define ABI_XINPUT_VERSION   SET_ABI_VERSION(3, 1)
> -#define ABI_EXTENSION_VERSIONSET_ABI_VERSION(1, 1)
> +#define ABI_VIDEODRV_VERSION SET_ABI_VERSION(5, 0)
> +#define ABI_XINPUT_VERSION   SET_ABI_VERSION(4, 0)

ABI_XINPUT_VERSION was bumped with the MPX merge, thus 3 is already the
correct version (server 1.5 has 2, btw.) Should we revert part of this patch?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] xf86-input-synaptics: update .gitignore

[Peter Hutterer]

On Thu, Oct 09, 2008 at 11:41:27PM +0100, Magnus Kessler wrote:
> The attached patch lets git ignore pkgconfig files.

Thanks, pushed.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] RFC: remove support for XInput ABI 0.x from xf86-input-synaptics driver

[Peter Hutterer]

On Thu, Oct 09, 2008 at 11:50:40PM +0100, Magnus Kessler wrote:
> This series of patches removes support for the ancient XInput ABI 0.x from 
> the synaptics driver, which in turn makes some more cleanup patches 
> possible. There seems to be a consensus that supporting XInput ABI older 
> than 2.x is not really needed any more [1].


03-errorf - applied, thanks.

02-DBG removal
instead of removing DBG calls maybe it would be better to convert them to
conditional xf86Msg's instead?

01-ABI removal - no.
Though I don't really have any problems with the patch from my POV, one reply
to your email hardly counts as consensus. and I think the few lines that are
used for ABI 0 aren't really distracting, so we might as well leave them in.
You'd need to find someone else to push that one :)

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Thu, Oct 09, 2008 at 03:42:50PM +0200, Simon Thum wrote:
> One non-ignoring handler is invoked at max. For this we have to
> differentiate the RC.

> When a handler is invoked, it may decide to call a new function which
> allows it to pass through to handlers AFTER itself. A logical complement
> would be the ability to register handlers at head and tail.

something like

--
RegisterHandler(myHandler, HEAD);
RegisterHandler(otherHandler, TAIL);

void myHandler(foo) {

   CallNextHandler(); /* causes otherHandler to be called */
   return PROP_HANDLED;
}
--

Where CallNextHandler calls the handler next in the queue.
Do I get that right? 

If so, a few questions:
- A handler that registers at the head of the queue, assumes it is before
  other handlers. Thus it has to be aware of other handlers in the first
  place?
- Two handlers that place themselves at the head of the queue now both assume
  they are called first?
- What if the handler order has to be different for each property?
- What reason would a handler have for registering at the tail, other than
  that it doesn't care whether it is ever called or not? 
  At which point - what's the point of this handler anyway?
- if myHandler allows pass-through after changing state, what if otherHandler
  returns an error code?

(I do have the feeling that I didn't quite understand you proposal)
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] xf86-input-synaptics: Return correctly on successful property setting

[Peter Hutterer]

On Fri, Oct 10, 2008 at 09:04:58PM +1100, William Grant wrote:
> TRUE was not replaced with Success when all of the other property
> handler return codes were. This meant that properties ended up set in
> the driver but not the rest of the server.

Pushed as db6e631d31d4ffd476ccd105f8adb8d8b4727b29. Thanks for the patch!

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: To be sure, to be sure

[Peter Hutterer]

On Sat, Oct 11, 2008 at 03:27:48PM +0100, Colin Harrison wrote:
> There is a double up of some code in dix/events.c, function
> ReleaseActiveGrabs(), that may give
> trouble?
> 
> at about line 1920
> 
> if (dev->deviceGrab.grab && SameClient(dev->deviceGrab.grab,
> client))
> {
> (*dev->deviceGrab.DeactivateGrab)(dev);
> done = FALSE;
> }

You're right, it needs to be removed. 
But it won't do any harm, as dev->deviceGrab.grab is NULL after the first call
to DeactivateGrab anyway, so this condition can never be triggered.
I got the patch in my tree, will find its way upstream soon.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Fri, Oct 10, 2008 at 11:54:56AM +0200, Simon Thum wrote:
> > If so, a few questions:
> > - A handler that registers at the head of the queue, assumes it is before
> >   other handlers. Thus it has to be aware of other handlers in the first
> >   place?
> Yes, that would be the uncommon case, in which we should be well aware
> we're doing something special.
> 
> > - Two handlers that place themselves at the head of the queue now both 
> > assume
> >   they are called first?
> That's an assumption you shouldn't make. You can make the assumption
> that you're called before the others already in.
> 
> > - What if the handler order has to be different for each property?
> You need two handlers. Keep in mind handlers may well handle different
> property sets, so order can't depend on the prop alone.

So in light of the three answers here, I don't understand how this is an
improvement to the proposed patch that sparked this thread.
The patch I proposed does not make any guarantee over when a handler is
called. This automatically separates handlers so they cannot interfere with
each other, and dependency ordering is a nonissue, as you cannot rely on it to
begin with. Code that relies on other handlers should not end up in the
repository. 

> > - if myHandler allows pass-through after changing state, what if 
> > otherHandler
> >   returns an error code?
> That's indeed a problem. You shouldn't do it :)
> Either you call the rest first, if that's impossible, you should be
> prepared to undo stuff.
> 
> [...]
> 
> You also might want to consider this:
> http://www.cs.clemson.edu/~malloy/courses/patterns/chain.html

I think we're disagreeing over the underlying purpose of handlers.
In my view, a property handler is a simple piece of code that changes
some local settings. e.g. the emulateWheel boolean in the evdev driver.
Due to the local nature, you may need multiple handlers simultaneously.
e.g. a "debug" property, that triggers debugging spew in the driver, in the
dix, and in the ddx.

Right now, we pass into each handler and may end up with inconsistent state if
it fails halfway through.
With the proposed patch, we simply check first if _all_ handlers can deal with
the property change. If not, nothing happens and an error is returned. Only if
all handlers guarantee that the change will work, they are instructed to
perform the change. At this point, failure can only be caused by bugs.

The chain of command either limits yourself to one handler, or you require
undoability in the handlers, complicating code that should only trigger a few
flags to be set. I don't disagree with the design pattern, I just don't think
it is the right one for the purpose.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [PATCH] Xi: check all handlers before applying property changes.

[Peter Hutterer]

On Sun, Oct 12, 2008 at 06:17:20PM +0200, Simon Thum wrote:
> Peter Hutterer wrote:
> > The patch I proposed does not make any guarantee over when a handler is
> > called. This automatically separates handlers so they cannot interfere with
> > each other, and dependency ordering is a nonissue, as you cannot rely on it 
> > to
> > begin with. Code that relies on other handlers should not end up in the
> > repository. 
> Ok, if handlers can be kept independent, your solution is absolutely
> fine. Its also desirable to keep them independent.
> 
> I'm just not sure this is the whole story. When we look at the axis
> inversion example, this is rather insufficient. And it provokes
> workarounds, such as those you described.
> 
> I think the choice depends on how often conflicts occur and how hard it
> gets to deal with them. Unfortunately, I can't find my crystal sphere ;)

Thx. I just went ahead and pushed the patch. Since the whole thing is
server-internal anyway, it'll be easy to change if the need comes up later.
For now, the rule is that handlers should not touch anything outside of their
scope, and they cannot rely on being called in any particular order.

Let's see if that works. We got until december to find out I think :)

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] xfree86: if AllowEmptyInput is true, enable RAW mode on the console.

[Peter Hutterer]

Usually, the console is set to RAW in the kbd driver. If we hotplug all input
devices (i.e. the evdev driver for keyboards), the console is left as-is.
As a result, the evdev driver must put an EVIOCGRAB on the device to avoid
characters leaking onto the console. This again breaks many things, amongst
them lirc, in-kernel mouse button emulation and HAL.

This patch sets the console to RAW if AllowEmptyInput is on.

Use-cases:
1. AEI is off
  1.1. Only kbd driver is used - behaviour as-is.
  1.2. kbd and evdev driver is used: if evdev does not grab the device,
   duplicate events are generated.
2. AEI is on
  2.1. Only evdev driver is used - behaviour as-is, but evdev does not need
   to grab the device anymore.
  2.2. evdev and kbd are used: duplicate key events are generated if evdev
   does not grab the device.

1.2 is a marginal use-case that can be fixed by adding a "grab" option to the
evdev driver (update of xorg.conf is needed).

2.2 is an issue. If we have no ServerLayout section, AEI is on, but devices
specified in the xorg.conf are still added [1], resulting in duplicate events.
This is a common configuration and needs sorting out.

[1] 2eaed4a10fe5bf727579bca4ab8d4a47c8763a7d
---
 hw/xfree86/os-support/linux/lnx_init.c |   35 +++-
 1 files changed, 34 insertions(+), 1 deletions(-)

diff --git a/hw/xfree86/os-support/linux/lnx_init.c 
b/hw/xfree86/os-support/linux/lnx_init.c
index 4c36b7c..6136429 100644
--- a/hw/xfree86/os-support/linux/lnx_init.c
+++ b/hw/xfree86/os-support/linux/lnx_init.c
@@ -53,6 +53,8 @@ static int activeVT = -1;
 
 static int vtPermSave[4];
 static char vtname[11];
+static struct termios tty_attr; /* tty state to restore */
+static int tty_mode; /* kbd mode to restore */
 
 static int
 saveVtPerms(void)
@@ -272,6 +274,34 @@ xf86OpenConsole(void)
FatalError("xf86OpenConsole: KDSETMODE KD_GRAPHICS failed %s\n",
   strerror(errno));
 
+   /* Set the keyboard to RAW mode. If we're using the keyboard
+* driver, the driver does it for us. If we have AEI on, then
+* we're expecting the devices to be added (i.e. evdev) and we
+* have to set it manually.
+*/
+   if (xf86Info.allowEmptyInput)
+   {
+   struct termios nTty;
+
+   if (ioctl(xf86Info.consoleFd, KDSKBMODE, K_RAW) < 0)
+   FatalError("xf86OpenConsole: KDSKBMODE K_RAW failed %s\n",
+   strerror(errno));
+
+   ioctl(xf86Info.consoleFd, KDGKBMODE, &tty_mode);
+   tcgetattr(xf86Info.consoleFd, &tty_attr);
+
+   nTty = tty_attr;
+   nTty.c_iflag = (IGNPAR | IGNBRK) & (~PARMRK) & (~ISTRIP);
+   nTty.c_oflag = 0;
+   nTty.c_cflag = CREAD | CS8;
+   nTty.c_lflag = 0;
+   nTty.c_cc[VTIME]=0;
+   nTty.c_cc[VMIN]=1;
+   cfsetispeed(&nTty, 9600);
+   cfsetospeed(&nTty, 9600);
+   tcsetattr(xf86Info.consoleFd, TCSANOW, &nTty);
+   }
+
/* we really should have a InitOSInputDevices() function instead
 * of Init?$#*&Device(). So I just place it here */

@@ -328,7 +358,10 @@ xf86CloseConsole()
 if (ioctl(xf86Info.consoleFd, KDSETMODE, KD_TEXT) < 0)
xf86Msg(X_WARNING, "xf86CloseConsole: KDSETMODE failed: %s\n",
strerror(errno));
-   
+
+ioctl(xf86Info.consoleFd, KDSKBMODE, tty_mode);
+tcsetattr(xf86Info.consoleFd, TCSANOW, &tty_attr);
+
 if (ioctl(xf86Info.consoleFd, VT_GETMODE, &VT) < 0) 
xf86Msg(X_WARNING, "xf86CloseConsole: VT_GETMODE failed: %s\n",
strerror(errno));
-- 
1.6.0.1

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: keysymdef.h has wrong implies symbol?

[Peter Hutterer]

On Tue, Oct 14, 2008 at 02:16:22PM +0200, Erik Streb del Toro wrote:
> When I have “implies”¹ in my xkbmap it produces not the expected
>   U+21D2 RIGHTWARDS DOUBLE ARROW
> as described in the comment of keysymdef.h but the symbol
>   U+22A2 RIGHT TACK
>
> But this only in KDE apps not in Gnome/GTK. But if I use the X input  
> method by typing
>   export GTK_IM_MODULE=xim
> then all GTK apps produce the wrong symbol, too.

Could this be the fix? Applies to libX11.
(I don't claim that I know what I'm doing here).

diff --git a/src/xlibi18n/imKStoUCS.c b/src/xlibi18n/imKStoUCS.c
index 83c1483..4b4f628 100644
--- a/src/xlibi18n/imKStoUCS.c
+++ b/src/xlibi18n/imKStoUCS.c
@@ -120,7 +120,7 @@ static unsigned short const keysym_to_unicode_8a4_8fe[] = {
 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, /* 
0x08b0-0x08b7 */
 0x, 0x, 0x, 0x, 0x2264, 0x2260, 0x2265, 0x222b, /* 
0x08b8-0x08bf */
 0x2234, 0x, 0x221e, 0x, 0x, 0x2207, 0x, 0x, /* 
0x08c0-0x08c7 */
-0x2245, 0x2246, 0x, 0x, 0x, 0x, 0x22a2, 0x, /* 
0x08c8-0x08cf */
+0x2245, 0x2246, 0x, 0x, 0x, 0x, 0x21d2, 0x, /* 
0x08c8-0x08cf */
 0x, 0x, 0x, 0x, 0x, 0x, 0x221a, 0x, /* 
0x08d0-0x08d7 */
 0x, 0x, 0x2282, 0x2283, 0x2229, 0x222a, 0x2227, 0x2228, /* 
0x08d8-0x08df */
 0x, 0x, 0x, 0x, 0x, 0x, 0x, 0x, /* 
0x08e0-0x08e7 */

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: patch: use Xrecord extension in syndaemon to avoid polling

[Peter Hutterer]

On Mon, Oct 13, 2008 at 04:35:37PM +0200, Andre Herms wrote:
>Attached is a patch for the syndaemon of the synaptics driver. It
>prevents the
>polling of the keyboard state. Instead it uses the XRecord extension of
>the
>Xserver for an event triggered notification of key events. Of course,
>there
>is a fallback to the polling when no XRecord extension is found. This
>should
>finally stop complains of syndaemon preventing good power saving.
>Comments are welcome.

Thanks for the patch! There's a number of irrelevant white-space changes in
that patch. Can you please clean it up and re-send it? Thanks.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] xfree86: Parse adaptive and constant deceleration as floats.

[Peter Hutterer]

They are stored in floats, so we might as well take them like they are. Plus,
this way keith's mouse can be configured to his liking.

Spotted by Keith Packard.
---
 hw/xfree86/common/xf86Xinput.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 8eaa118..a1d9f67 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -124,7 +124,7 @@ ProcessVelocityConfiguration(char* devname, pointer list, 
DeviceVelocityPtr s){
xf86Msg(X_CONFIG, "%s: (accel) filter stage %i: %.2f ms\n",
 devname, i, 1.0f / (s->filters[i].rdecay));
 
-tempf = xf86SetIntOption(list, "ConstantDeceleration", 1);
+tempf = xf86SetRealOption(list, "ConstantDeceleration", 1);
 if(tempf > 1.0){
 xf86Msg(X_CONFIG, "%s: (accel) constant deceleration by %.1f\n",
 devname, tempf);
@@ -132,7 +132,7 @@ ProcessVelocityConfiguration(char* devname, pointer list, 
DeviceVelocityPtr s){
   alias acceleration */
 }
 
-tempf = xf86SetIntOption(list, "AdaptiveDeceleration", 1);
+tempf = xf86SetRealOption(list, "AdaptiveDeceleration", 1);
 if(tempf > 1.0){
 xf86Msg(X_CONFIG, "%s: (accel) adaptive deceleration by %.1f\n",
 devname, tempf);
-- 
1.5.4.3
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [xorg-server-1.5.2] Mouse wheel trouble

[Peter Hutterer]

On Thu, Oct 16, 2008 at 11:10:39PM +0200, Tobias Jakobi wrote:
> The problem: When starting/restarting the xserver the mousewheel does not
> work. Investigating with xev reveals that the wheel generates button events
> 6 and 7.
> 
> How to get the mouse working: Unplug and replug the device, then the wheel
> starts working. However now the wheel does produce button events 4 and 5.
> 
> I assume that should not happen at all. I'm currently hotfixing this by
> letting a script do a modprobe -r uhci-hcd, sleeping and loading the module
> again (which does essentially the same like unplugging and replugging the
> mouse).
> 

you don't have any button mapping set, do you?
can you run evtest on the device file and post the output when the wheel
doesn't work? (you have to do that without X running, otherwise it'll grab the
device from you).

the wheel code in evdev is fairly simple, so I'd wager a bet on either
configuration or hw issues.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [xorg-server-1.5.2] Mouse wheel trouble

[Peter Hutterer]

On Fri, Oct 17, 2008 at 02:42:31AM +0200, Tobias Jakobi wrote:
>type="string">true

You don't need this option, it's the default anyway.

>type="string">Buttons 5 4

this option isn't parsed by evdev, so it doesn't have any effect.

> I have some settings in the /etc/hal/fdi/policy/10-x11-input.fdi.
> I added the RelHWHEELMapTo setting after the device did not work, but
> that didn't seem to fix it. If I remove the setting nothing changes. The
> mouse still doesn't work after a restart of X (buttons 6 and 7 are
> assigned to the wheel, which doesn't seem to be that what X expects) and
> replugging makes the wheel work again.

xmodmap -pp when the buttons are screwed up. is the mapping 4:4 and 5:5?

> Testing ... (interrupt to exit)
> Event: time 1224203149.075801, type 2 (Relative), code 8 (Wheel), value -1
> Event: time 1224203149.075803, -- Report Sync 
> Event: time 1224203149.363751, type 2 (Relative), code 8 (Wheel), value 1
> Event: time 1224203149.363757, -- Report Sync 

the matching code in evdev is:
   case REL_WHEEL:
if (value > 0)
PostButtonClicks(pInfo, wheel_up_button, value);
if (value < 0)
PostButtonClicks(pInfo, wheel_down_button, -value);
break;

where wheel_up_button and wheel_down_button are hardcoded to 4/5. So I don't
quite see what can go wrong there.

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-evdev 2.0.7

[Peter Hutterer]

Julien Cristau (1):
  Set pInfo->fd to -1 on DEVICE_CLOSE

Peter Hutterer (3):
  Fix "Device reopened after N attempts" message.
  Don't post keycodes > 255.
  evdev 2.0.7

git tag: xf86-input-evdev-2.0.7

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.7.tar.bz2
MD5: cda012a05bcbe8fbad46ea338ad1716e  xf86-input-evdev-2.0.7.tar.bz2
SHA1: f7e6148e7772cf23ee6107748279cfd428ae2195  xf86-input-evdev-2.0.7.tar.bz2

http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.0.7.tar.gz
MD5: dfc928707c3250c4813e7e284793b275  xf86-input-evdev-2.0.7.tar.gz
SHA1: 6113b799311668417bc42d1eef3d5c4fa231f42d  xf86-input-evdev-2.0.7.tar.gz
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[ANNOUNCE] xf86-input-evdev 2.0.99.1

[Peter Hutterer]

Announcing RC1 of evdev 2.1.

Long overdue, it provides a number of features over the current stable 2.0:

- The driver forces the "evdev" ruleset and thus allows other xkb models than
  "evdev" to be selected without further repercussions (requires
  xkeyboard-config 1.4).
- Mouse wheel emulation enables to scroll while holding a button and moving
  the mouse left/right or up/down.
- Axis inversion enables you to use devices upside-down. Handy for bats and
  those on the southern hemisphere.
- Drag lock simulates a continuous button down for low dexterity people.
- Property support provides run-time modification for the above features.
  Requires an X server from git.

And lots of fixes and cleanups. Let's get this thing tested.

git shortlog since evdev 2.0.0:

Adam Jackson (1):
  Print a warning if a keycode exceeds the range accepted by the server.

Ander Conselvan de Oliveira (1):
  Mice with a lot of buttons (e.g. Logitech MX1000) generate button events 
greater than BTN_TASK.

Chris Salch (4):
  Adding a function to map button events to button numbers.
  Adding mouse wheel emulation code.
  Filter wheel events before middle mouse button emulation.
  Adding in DragLockButtons functionality.

Dan Nicholson (2):
  Add timeout support for mouse wheel emulation
  Add wheel timeout property support

Daniel Stone (1):
  Force rules, not model, to be evdev

Julien Cristau (4):
  Fill up the version info
  Print the device name when we get a read error
  Actually close the fd on DEVICE_CLOSE (bug#16948)
  Set pInfo->fd to -1 on DEVICE_CLOSE

Keith Packard (1):
  Enable middle button emulation at DEVICE_ON instead of DEVICE_INIT.

Michel Dänzer (1):
  xf86-input-evdev: Fix EVIOCGBIT ioctl usage on big endian platforms.

Peter Hutterer (55):
  No need to finalize MB emulation after EvdevProbe anymore.
  Bump to 2.0.99.
  Count buttons at probe and print to log.
  Remove EvdevConvert, nobody calls it now anyway.
  Remove stale comments.
  Update COPYING with the correct copyright info.
  Remove static ChangeLog, autogenerate as part of make dist.
  Clean out configure.ac
  Add support for device properties, currently MB emulation and timeout.
  Add .gitignore file.
  Don't enable the device if the grab failed with ENODEV.
  Guard property changes against ABI_XINPUT < 3.
  Add support for ButtonMapping option.
  Expose wheel emulation through device properties.
  Add EVDEV_MAXBUTTONS instead of checking against 32.
  Simplify the property handler registration.
  Don't grab devices unless specified through the config options.
  Revert "Don't grab devices unless specified through the config options."
  Add property support for drag lock.
  Init all emulateWheel values, even if EmulateWheel is disabled.
  Wheel emulation: initial values must be char.
  Shut up "unused variable" compiler warnings.
  Use HAVE_PROPERTIES define instead of GET_ABI_MAJOR for property 
compilation.
  Attempt to re-open devices on read errors.
  Don't require randrproto.
  draglock: Shut up compiler warning.
  Use new property API (no ConfigureDP, less args to ChangeDP)
  Add evdev-properties.h file with #defines for all property names.
  Cleanup: "valid_vals" should be "vals" now.
  Register property handlers directly, instead of abstracting them.
  Move misplaced #endif
  Change DragLock atom name - prepend with Evdev.
  Remove useless initialization of rc.
  Close fd on DEVICE_OFF. (LP #276887)
  Install xorg-evdev.pc for clients who need evdev-properties.h
  Add property support for axis inversion.
  Stricter value checking for property changes.
  Fix up bad return code in draglock property handler.
  Add checkonly handling to property handlers.
  Janitor: purge unused headers, reshuffle for readability, fix whitespace 
errors.
  Remove parsing of ScreenNumber option.
  Remove "Path" option.
  Document InvertX/Y options.
  Document properties in man page.
  Add property support for ReopenAttempts option.
  Janitor: clean up xf86Msg use, might as well use X_CONFIG directly.
  Clean up program flow - don't call PreInit for "modules" on DEVICE_INIT.
  Register property handler from within the modules, not the main evdev 
file.
  Rename DragLockInit to DragLockPreInit, remove superfluous "return".
  Tidy up evdev.h
  Don't include the client-side header anymore. xkbstr.h is server SDK.
  8-bit properties should use 8-bit storage types...
  Don't init draglock, etc. if we don't have the required capabilities.
  Fix "Device reopened after N attempts" message.
  evdev 2.1 RC 1.

Simon Munton (1):
  Close file des

Re: [patch 4/8] Cygwin update for MPX device changes

[Peter Hutterer]

ACK - untested though.

On Thu, Oct 16, 2008 at 01:10:01PM +0100, [EMAIL PROTECTED] wrote:
> ---
>  xserver/hw/xwin/InitInput.c |   16 +---
>  xserver/hw/xwin/win.h   |2 ++
>  xserver/hw/xwin/winmultiwindowwndproc.c |4 ++--
>  xserver/hw/xwin/winwndproc.c|4 ++--
>  4 files changed, 15 insertions(+), 11 deletions(-)
> 
> Index: xorg-git/xserver/hw/xwin/InitInput.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/InitInput.c
> +++ xorg-git/xserver/hw/xwin/InitInput.c
> @@ -49,6 +49,8 @@ DISPATCH_PROC(winProcSetSelectionOwner);
>   */
>  
>  CARD32   g_c32LastInputEventTime = 0;
> +DeviceIntPtr g_pwinPointer;
> +DeviceIntPtr g_pwinKeyboard;
>  
>  
>  /*
> @@ -94,7 +96,6 @@ ProcessInputEvents (void)
>  #endif
>  
>mieqProcessInputEvents ();
> -  miPointerUpdate ();
>  
>  #if 0
>ErrorF ("ProcessInputEvents - returning\n");
> @@ -122,8 +123,6 @@ TimeSinceLastInputEvent ()
>  void
>  InitInput (int argc, char *argv[])
>  {
> -  DeviceIntPtr   pMouse, pKeyboard;
> -
>  #if CYGDEBUG
>winDebug ("InitInput\n");
>  #endif
> @@ -145,11 +144,14 @@ InitInput (int argc, char *argv[])
>  }
>  #endif
>  
> -  pMouse = AddInputDevice (winMouseProc, TRUE);
> -  pKeyboard = AddInputDevice (winKeybdProc, TRUE);
> +  g_pwinPointer = AddInputDevice (serverClient, winMouseProc, TRUE);
> +  g_pwinKeyboard = AddInputDevice (serverClient, winKeybdProc, TRUE);
>
> -  RegisterPointerDevice (pMouse);
> -  RegisterKeyboardDevice (pKeyboard);
> +  RegisterPointerDevice (g_pwinPointer);
> +  RegisterKeyboardDevice (g_pwinKeyboard);
> +
> +  g_pwinPointer->name = strdup("Windows mouse");
> +  g_pwinKeyboard->name = strdup("Windows keyboard");
>  
>miRegisterPointerDevice (screenInfo.screens[0], pMouse);
>mieqInit ((DevicePtr)pKeyboard, (DevicePtr)pMouse);
> Index: xorg-git/xserver/hw/xwin/win.h
> ===
> --- xorg-git.orig/xserver/hw/xwin/win.h
> +++ xorg-git/xserver/hw/xwin/win.h
> @@ -639,6 +639,8 @@ extern HINSTANCE  g_hInstance;
>  extern int  g_copyROP[];
>  extern int  g_patternROP[];
>  extern const char *  g_pszQueryHost;
> +extern DeviceIntPtr g_pwinPointer;
> +extern DeviceIntPtr g_pwinKeyboard;
>  
>  
>  /*
> Index: xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmultiwindowwndproc.c
> +++ xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> @@ -495,8 +495,8 @@ winTopLevelWindowProc (HWND hwnd, UINT m
>   break;
>  
>/* Has the mouse pointer crossed screens? */
> -  if (s_pScreen != miPointerGetScreen(inputInfo.pointer))
> - miPointerSetScreen (inputInfo.pointer, s_pScreenInfo->dwScreen,
> +  if (s_pScreen != miPointerGetScreen(g_pwinPointer))
> + miPointerSetScreen (g_pwinPointer, s_pScreenInfo->dwScreen,
>  ptMouse.x - s_pScreenInfo->dwXOffset,
>  ptMouse.y - s_pScreenInfo->dwYOffset);
>  
> Index: xorg-git/xserver/hw/xwin/winwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winwndproc.c
> +++ xorg-git/xserver/hw/xwin/winwndproc.c
> @@ -724,8 +724,8 @@ winWindowProc (HWND hwnd, UINT message, 
>   break;
>  
>/* Has the mouse pointer crossed screens? */
> -  if (s_pScreen != miPointerGetScreen(inputInfo.pointer))
> - miPointerSetScreen (inputInfo.pointer, s_pScreenInfo->dwScreen,
> +  if (s_pScreen != miPointerGetScreen(g_pwinPointer))
> + miPointerSetScreen (g_pwinPointer, s_pScreenInfo->dwScreen,
>  GET_X_LPARAM(lParam)-s_pScreenInfo->dwXOffset,
>  GET_Y_LPARAM(lParam)-s_pScreenInfo->dwYOffset);
>  
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [patch 6/8] Cygwin update to enqueue pointer motion event on mouse movement

[Peter Hutterer]

On Thu, Oct 16, 2008 at 01:10:03PM +0100, [EMAIL PROTECTED] wrote:
> Apparently we shouldn't need this, something else is wrong...

no, I was wrong in the previous email, confusing the intention of the code
here. Am I right that this is the interface between X and the windows API? 

In that case winEnqueueMotion should do the same as xf86PostMotionEventP, minus
the DGA stuff I guess.

ACK, though untested.

 
> ---
>  xserver/hw/xwin/win.h |3 +++
>  xserver/hw/xwin/winmouse.c|   26 ++
>  xserver/hw/xwin/winmultiwindowwndproc.c   |6 +++---
>  xserver/hw/xwin/winwin32rootlesswndproc.c |6 +++---
>  xserver/hw/xwin/winwndproc.c  |8 +++-
>  5 files changed, 38 insertions(+), 11 deletions(-)
> 
> Index: xorg-git/xserver/hw/xwin/win.h
> ===
> --- xorg-git.orig/xserver/hw/xwin/win.h
> +++ xorg-git/xserver/hw/xwin/win.h
> @@ -1006,6 +1006,9 @@ winMouseButtonsHandle (ScreenPtr pScreen
>  int iEventType, int iButton,
>  WPARAM wParam);
>  
> +void
> +winEnqueueMotion(int x, int y);
> +
>  #ifdef XWIN_NATIVEGDI
>  /*
>   * winnativegdi.c
> Index: xorg-git/xserver/hw/xwin/winmouse.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmouse.c
> +++ xorg-git/xserver/hw/xwin/winmouse.c
> @@ -344,3 +344,29 @@ winMouseButtonsHandle (ScreenPtr pScreen
>  
>return 0;
>  }
> +
> +/**
> + * Enqueue a motion event.
> + *
> + *  XXX: miPointerMove does exactly this, but is static :-( (and uses a 
> static buffer)
> + *
> + */
> +void winEnqueueMotion(int x, int y)
> +{
> +  miPointerSetPosition(g_pwinPointer, &x, &y);
> +  g_c32LastInputEventTime = GetTickCount();
> +
> +  int i, nevents;
> +  int valuators[2];
> +
> +  EventListPtr events;
> +  GetEventList(&events);
> +
> +  valuators[0] = x;
> +  valuators[1] = y;
> +  nevents = GetPointerEvents(events, g_pwinPointer, MotionNotify, 0,
> +  POINTER_ABSOLUTE, 0, 2, valuators);
> +
> +  for (i = 0; i < nevents; i++)
> +mieqEnqueue(g_pwinPointer, events[i].event);
> +}
> Index: xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmultiwindowwndproc.c
> +++ xorg-git/xserver/hw/xwin/winmultiwindowwndproc.c
> @@ -535,9 +535,9 @@ winTopLevelWindowProc (HWND hwnd, UINT m
>   }
>  
>/* Deliver absolute cursor position to X Server */
> -  miPointerAbsoluteCursor (ptMouse.x - s_pScreenInfo->dwXOffset,
> -ptMouse.y - s_pScreenInfo->dwYOffset,
> -g_c32LastInputEventTime = GetTickCount ());
> +  winEnqueueMotion(ptMouse.x - s_pScreenInfo->dwXOffset,
> +ptMouse.y - s_pScreenInfo->dwYOffset);
> +
>return 0;
>
>  case WM_NCMOUSEMOVE:
> Index: xorg-git/xserver/hw/xwin/winwin32rootlesswndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winwin32rootlesswndproc.c
> +++ xorg-git/xserver/hw/xwin/winwin32rootlesswndproc.c
> @@ -571,9 +571,9 @@ winMWExtWMWindowProc (HWND hwnd, UINT me
>   }
>  
>/* Deliver absolute cursor position to X Server */
> -  miPointerAbsoluteCursor (ptMouse.x - pScreenInfo->dwXOffset,
> -ptMouse.y - pScreenInfo->dwYOffset,
> -g_c32LastInputEventTime = GetTickCount ());
> +  winEnqueueMotion(ptMouse.x - pScreenInfo->dwXOffset,
> +ptMouse.y - pScreenInfo->dwYOffset);
> +
>return 0;
>
>  case WM_NCMOUSEMOVE:
> Index: xorg-git/xserver/hw/xwin/winwndproc.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winwndproc.c
> +++ xorg-git/xserver/hw/xwin/winwndproc.c
> @@ -764,9 +764,8 @@ winWindowProc (HWND hwnd, UINT message, 
>   }
>
>/* Deliver absolute cursor position to X Server */
> -  miPointerAbsoluteCursor (GET_X_LPARAM(lParam)-s_pScreenInfo->dwXOffset,
> -GET_Y_LPARAM(lParam)-s_pScreenInfo->dwYOffset,
> -g_c32LastInputEventTime = GetTickCount ());
> +  winEnqueueMotion(GET_X_LPARAM(lParam)-s_pScreenInfo->dwXOffset,
> +GET_Y_LPARAM(lParam)-s_pScreenInfo->dwYOffset);
>return 0;
>  
>  case WM_NCMOUSEMOVE:
> @@ -929,8 +928,7 @@ winWindowProc (HWND hwnd, UINT message, 
>   point.y -= GetSystemMetrics (SM_YVIRTUALSCREEN);
>   
>   /* Deliver absolute cursor position to X Server */
> - miPointerAbsoluteCursor (point.x, point.y,
> -  g_c32LastInputEventTime = GetTickCount());
> + winEnqueueMotion(point.x , point.y);
>  
>   /* Check if a button was released but we

Re: [patch 3/8] Cygwin update for MPX cursor API changes

[Peter Hutterer]

ACK, untested.

On Thu, Oct 16, 2008 at 01:10:00PM +0100, [EMAIL PROTECTED] wrote:
> ---
>  xserver/hw/xwin/wincursor.c |   33 -
>  1 file changed, 24 insertions(+), 9 deletions(-)
>  
> Index: xorg-git/xserver/hw/xwin/wincursor.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/wincursor.c
> +++ xorg-git/xserver/hw/xwin/wincursor.c
> @@ -62,7 +62,7 @@ extern Bool g_fSoftwareCursor;
>   */
>  
>  static void
> -winPointerWarpCursor (ScreenPtr pScreen, int x, int y);
> +winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y);
>  
>  static Bool
>  winCursorOffScreen (ScreenPtr *ppScreen, int *x, int *y);
> @@ -79,7 +79,7 @@ miPointerScreenFuncRec g_winPointerCurso
>  
>  
>  static void
> -winPointerWarpCursor (ScreenPtr pScreen, int x, int y)
> +winPointerWarpCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
>  {
>winScreenPriv(pScreen);
>RECT   rcClient;
> @@ -119,7 +119,7 @@ winPointerWarpCursor (ScreenPtr pScreen,
>  }
>  
>/* Call the mi warp procedure to do the actual warping in X. */
> -  miPointerWarpCursor (pScreen, x, y);
> +  miPointerWarpCursor (pDev, pScreen, x, y);
>  }
>  
>  static Bool
> @@ -436,7 +436,7 @@ winLoadCursor (ScreenPtr pScreen, Cursor
>   *  Convert the X cursor representation to native format if possible.
>   */
>  static Bool
> -winRealizeCursor (ScreenPtr pScreen, CursorPtr pCursor)
> +winRealizeCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor)
>  {
>if(pCursor == NULL || pCursor->bits == NULL)
>  return FALSE;
> @@ -452,7 +452,7 @@ winRealizeCursor (ScreenPtr pScreen, Cur
>   *  Free the storage space associated with a realized cursor.
>   */
>  static Bool
> -winUnrealizeCursor(ScreenPtr pScreen, CursorPtr pCursor)
> +winUnrealizeCursor(DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor)
>  {
>return TRUE;
>  }
> @@ -463,7 +463,7 @@ winUnrealizeCursor(ScreenPtr pScreen, Cu
>   *  Set the cursor sprite and position.
>   */
>  static void
> -winSetCursor (ScreenPtr pScreen, CursorPtr pCursor, int x, int y)
> +winSetCursor (DeviceIntPtr pDev, ScreenPtr pScreen, CursorPtr pCursor, int 
> x, int y)
>  {
>POINT ptCurPos, ptTemp;
>HWND  hwnd;
> @@ -537,20 +537,35 @@ winSetCursor (ScreenPtr pScreen, CursorP
>  
>  
>  /*
> - * QuartzMoveCursor
> + * winMoveCursor
>   *  Move the cursor. This is a noop for us.
>   */
>  static void
> -winMoveCursor (ScreenPtr pScreen, int x, int y)
> +winMoveCursor (DeviceIntPtr pDev, ScreenPtr pScreen, int x, int y)
>  {
>  }
>  
> +static Bool
> +winDeviceCursorInitialize(DeviceIntPtr pDev, ScreenPtr pScr)
> +{
> +  winScreenPriv(pScr);
> +  return pScreenPriv->cursor.spriteFuncs->DeviceCursorInitialize(pDev, pScr);
> +}
> +
> +static void
> +winDeviceCursorCleanup(DeviceIntPtr pDev, ScreenPtr pScr)
> +{
> +  winScreenPriv(pScr);
> +  return pScreenPriv->cursor.spriteFuncs->DeviceCursorCleanup(pDev, pScr);
> +}
>  
>  static miPointerSpriteFuncRec winSpriteFuncsRec = {
>winRealizeCursor,
>winUnrealizeCursor,
>winSetCursor,
> -  winMoveCursor
> +  winMoveCursor,
> +  winDeviceCursorInitialize,
> +  winDeviceCursorCleanup
>  };
>  
>  
> 
> -- 
> ___
> xorg mailing list
> xorg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 
> 
> !DSPAM:48f73d37252165362964316!
> 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [patch 5/8] Cygwin update for changes in mieq API

[Peter Hutterer]

ACK, untested.

On Thu, Oct 16, 2008 at 01:10:02PM +0100, [EMAIL PROTECTED] wrote:
> ---
>  xserver/hw/xwin/InitInput.c |3 +--
>  xserver/hw/xwin/winkeybd.c  |   20 
>  xserver/hw/xwin/winmouse.c  |   25 +++--
>  3 files changed, 28 insertions(+), 20 deletions(-)
> 
> Index: xorg-git/xserver/hw/xwin/InitInput.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/InitInput.c
> +++ xorg-git/xserver/hw/xwin/InitInput.c
> @@ -153,8 +153,7 @@ InitInput (int argc, char *argv[])
>g_pwinPointer->name = strdup("Windows mouse");
>g_pwinKeyboard->name = strdup("Windows keyboard");
>  
> -  miRegisterPointerDevice (screenInfo.screens[0], pMouse);
> -  mieqInit ((DevicePtr)pKeyboard, (DevicePtr)pMouse);
> +  mieqInit ();
>  
>/* Initialize the mode key states */
>winInitializeModeKeyStates ();
> Index: xorg-git/xserver/hw/xwin/winkeybd.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winkeybd.c
> +++ xorg-git/xserver/hw/xwin/winkeybd.c
> @@ -580,7 +580,8 @@ winKeybdReleaseKeys ()
>  void
>  winSendKeyEvent (DWORD dwKey, Bool fDown)
>  {
> -  xEvent xCurrentEvent;
> +  EventListPtr events;
> +  int i, nevents;
>  
>/*
> * When alt-tabing between screens we can get phantom key up messages
> @@ -590,14 +591,17 @@ winSendKeyEvent (DWORD dwKey, Bool fDown
>  
>/* Update the keyState map */
>g_winKeyState[dwKey] = fDown;
> -  
> -  ZeroMemory (&xCurrentEvent, sizeof (xCurrentEvent));
>  
> -  xCurrentEvent.u.u.type = fDown ? KeyPress : KeyRelease;
> -  xCurrentEvent.u.keyButtonPointer.time =
> -g_c32LastInputEventTime = GetTickCount ();
> -  xCurrentEvent.u.u.detail = dwKey + MIN_KEYCODE;
> -  mieqEnqueue (&xCurrentEvent);
> +  GetEventList(&events);
> +  nevents = GetKeyboardEvents(events, g_pwinKeyboard, fDown ? KeyPress : 
> KeyRelease, dwKey + MIN_KEYCODE);
> +
> +  for (i = 0; i < nevents; i++)
> +mieqEnqueue(g_pwinKeyboard, events[i].event);
> +
> +#if CYGDEBUG
> +  ErrorF("winSendKeyEvent: dwKey: %d, fDown: %d, nEvents %d\n",
> +  dwKey, fDown, nevents);
> +#endif
>  }
>  
>  BOOL winCheckKeyPressed(WPARAM wParam, LPARAM lParam)
> Index: xorg-git/xserver/hw/xwin/winmouse.c
> ===
> --- xorg-git.orig/xserver/hw/xwin/winmouse.c
> +++ xorg-git/xserver/hw/xwin/winmouse.c
> @@ -100,7 +100,6 @@ winMouseProc (DeviceIntPtr pDeviceInt, i
>InitPointerDeviceStruct (pDevice,
>  map,
>  lngMouseButtons + lngWheelEvents,
> -GetMotionHistory,
>  winMouseCtrl,
>  GetMotionHistorySize(),
>  2);
> @@ -221,19 +220,25 @@ winMouseWheel (ScreenPtr pScreen, int iD
>  void
>  winMouseButtonsSendEvent (int iEventType, int iButton)
>  {
> -  xEvent xCurrentEvent;
> +  EventListPtr events;
> +  int i, nevents;
>  
> -  /* Load an xEvent and enqueue the event */
> -  xCurrentEvent.u.u.type = iEventType;
>  #if defined(XFree86Server)
>if (g_winMouseButtonMap)
> -xCurrentEvent.u.u.detail = g_winMouseButtonMap[iButton];
> -  else
> +iButton = g_winMouseButtonMap[iButton];
> +#endif
> +
> +  GetEventList(&events);
> +  nevents = GetPointerEvents(events, g_pwinPointer, iEventType, iButton,
> +  POINTER_RELATIVE, 0, 0, NULL);
> +
> +  for (i = 0; i < nevents; i++)
> +mieqEnqueue(g_pwinPointer, events[i].event);
> +
> +#if CYGDEBUG
> +  ErrorF("winMouseButtonsSendEvent: iEventType: %d, iButton: %d, nEvents 
> %d\n",
> +  iEventType, iButton, nevents);
>  #endif
> -  xCurrentEvent.u.u.detail = iButton;
> -  xCurrentEvent.u.keyButtonPointer.time
> -= g_c32LastInputEventTime = GetTickCount ();
> -  mieqEnqueue (&xCurrentEvent);
>  }
>  
>  
> 
> -- 
> ___
> xorg mailing list
> xorg@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 
> 
> !DSPAM:48f73b0a250731187917547!
> 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] config: don't add duplicate devices through HAL.

[Peter Hutterer]

If HAL is restarted, the device list is send to the server again, leading
first to duplicate devices (and thus duplicate events), and later to a
FatalError "Too many input devices."

dev->config_info contains the UDI for the device. If the UDI of a new devices
is equal to one we already have in the device list, just ignore it.
---
 config/hal.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/config/hal.c b/config/hal.c
index 0e0505b..639e0ec 100644
--- a/config/hal.c
+++ b/config/hal.c
@@ -166,6 +166,26 @@ get_prop_string_array(LibHalContext *hal_ctx, const char 
*udi, const char *prop)
 return ret;
 }
 
+static BOOL
+device_is_duplicate(char *config_info)
+{
+DeviceIntPtr dev;
+
+for (dev = inputInfo.devices; dev; dev = dev->next)
+{
+if (dev->config_info && (strcmp(dev->config_info, config_info) == 0))
+return TRUE;
+}
+
+for (dev = inputInfo.off_devices; dev; dev = dev->next)
+{
+if (dev->config_info && (strcmp(dev->config_info, config_info) == 0))
+return TRUE;
+}
+
+return FALSE;
+}
+
 static void
 device_added(LibHalContext *hal_ctx, const char *udi)
 {
@@ -227,6 +247,13 @@ device_added(LibHalContext *hal_ctx, const char *udi)
 }
 sprintf(config_info, "hal:%s", udi);
 
+/* Check for duplicate devices */
+if (device_is_duplicate(config_info))
+{
+LogMessage(X_WARNING, "config/hal: device %s already added. 
Ignoring.\n", name);
+goto unwind;
+}
+
 /* ok, grab options from hal.. iterate through all properties
 * and lets see if any of them are options that we can add */
 set = libhal_device_get_all_properties(hal_ctx, udi, &error);
-- 
1.6.0.1

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: XFixes and XI2

[Peter Hutterer]

On Sat, Oct 18, 2008 at 07:50:38AM +0800, Sam Spilsbury wrote:
> I'm continuing Peter Hutterer's MPX aware version of compiz and
> extending it to all of compiz-fusion. Some of the plugins use a call
> to XFixes to get a cursor image for the current cursor and to hide the
> current cursor. I didn't find any documentation as to if this is
> device-aware or not. If so, could someone tell me how to call it with
> reference to specific devices.

it is not device aware yet.

with cursors, there is two settings per window
1. the window cursor (as defined in the core protocol)
2. a device-specific cursor.

if 2 isn't defined for a specific device, all devices use 1. the xfixes
requests work only on 1., so while this is appropriate for most occasions, it
needs a device-aware implementation too.
 
Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

Re: [xorg-server-1.5.2] Mouse wheel trouble

[Peter Hutterer]

On Fri, Oct 17, 2008 at 08:45:09PM +0200, Tobias Jakobi wrote:
> > this option isn't parsed by evdev, so it doesn't have any effect.
> Hmm, are there currently any ways to configure evdev devices?
> The manpages seems a bit outdated. The is nearly nothing there that has
> to do with button mapping and such kind of stuff.

The man page is correct.

evdev 2.0.x doesn't parse button mapping options, and you have to use X protocol
requests to map the buttons (which is how clients do it anyway).

evdev 2.1 has the option, but this is done before the X server sees it and
cannot be changed by the client. This is mainly for devices that have busted
buttons, or need a permanent switch.

> > xmodmap -pp when the buttons are screwed up. is the mapping 4:4 and 5:5?
> Yeah, you're right.
> 
> When the mouse doesn't work I have a 4:6, 5:7, 6:4, 7:5 mapping. However
> I haven't got any entries in my Xmodmap file.
> 
> How can I see where these mappings come from?

some desktop environment setting?
if you just start X and xterm, does the mapping look the same?

Cheers,
  Peter
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg

[PATCH] xfree86: AllowEmptyInput is true by default - update the xf86Info defaults.

[Peter Hutterer]

AEI is true if we expect to get the devices from HAL. With
d936a4235c9625bd41569cef3452dd086284e0d7, AEI also triggers the console RAW
mode.

AEI is set depending on AutoAddDevices and AutoEnableDevices, but only if a
configuration file is present. If not, the console is opened before we can set
it and RAW mode is never set.

So let's simply set it to TRUE as default, since that's what it is by default
anyway (AutoAddDevices and AutoEnableDevices are true by default).

And while we're at it, switch the rest of the defaults over to named
intializers.

Signed-off-by: Peter Hutterer <[EMAIL PROTECTED]>
---
 hw/xfree86/common/xf86Globals.c |   55 ---
 1 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index f72f1b6..11d643d 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -98,37 +98,38 @@ InputInfoPtr xf86InputDevs = NULL;
 /* Globals that video drivers may not access */
 
 xf86InfoRec xf86Info = {
-   -1, /* consoleFd */
-   -1, /* vtno */
-   FALSE,  /* vtSysreq */
-   SKWhenNeeded,   /* ddxSpecialKeys */
-   -1, /* lastEventTime */
-   FALSE,  /* vtRequestsPending */
-   FALSE,  /* dontVTSwitch */
-   FALSE,  /* dontZap */
-   FALSE,  /* dontZoom */
-   FALSE,  /* notrapSignals */
-   FALSE,  /* caughtSignal */
-   NULL,   /* currentScreen */
+.consoleFd  = -1,
+.vtno   = -1,
+.vtSysreq   = FALSE,
+.ddxSpecialKeys = SKWhenNeeded,
+.lastEventTime  = -1,
+.vtRequestsPending  = FALSE,
+.dontVTSwitch   = FALSE,
+.dontZap= FALSE,
+.dontZoom   = FALSE,
+.notrapSignals  = FALSE,
+.caughtSignal   = FALSE,
+.currentScreen  = NULL,
 #ifdef CSRG_BASED
-   -1, /* screenFd */
-   -1, /* consType */
+.screenFd   = -1,
+.consType   = -1,
 #endif
-   FALSE,  /* allowMouseOpenFail */
-   TRUE,   /* vidModeEnabled */
-   FALSE,  /* vidModeAllowNonLocal */
-   TRUE,   /* miscModInDevEnabled */
-   FALSE,  /* miscModInDevAllowNonLocal */
-   Pix24DontCare,  /* pixmap24 */
-   X_DEFAULT,  /* pix24From */
+.allowMouseOpenFail = FALSE,
+.vidModeEnabled = TRUE,
+.vidModeAllowNonLocal   = FALSE,
+.miscModInDevEnabled= TRUE,
+.miscModInDevAllowNonLocal  = FALSE,
+.pixmap24   = Pix24DontCare,
+.pix24From  = X_DEFAULT,
 #ifdef __i386__
-   FALSE,  /* pc98 */
+.pc98   = FALSE,
 #endif
-   TRUE,   /* pmFlag */
-   LogNone,/* syncLog */
-   FALSE,  /* kbdCustomKeycodes */
-   FALSE,  /* disableRandR */
-   X_DEFAULT   /* randRFrom */
+.pmFlag = TRUE,
+.log= LogNone,
+.kbdCustomKeycodes  = FALSE,
+.disableRandR   = FALSE,
+.randRFrom  = X_DEFAULT,
+.allowEmptyInput= TRUE
 };
 const char *xf86ConfigFile = NULL;
 const char *xf86InputDeviceList = NULL;
-- 
1.5.4.3

___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg