), we probably shouldn't label them as touchscreens.
Yes, but all of this is in a has abs X/Y check. Keyboards presumably
don't have absolute X/Y axes?
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
X/Y, no rel X/Y and
BTN_LEFT? Or do you have other crazy devices doing that as well?
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg
other devices.
With the check for BTN_LEFT (or rather has_lmr) that shouldn't be an
issue.
I'l send an updated patch shortly.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
work very well. We already internally
translate BTN_TOUCH as BTN_LEFT, so accept this kind of devices as
touchscreens by checking for devices with BTN_LEFT, absolute X/Y and NO
relative X/Y axes.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
Changes since v1:
- Add as seperate check
,
Peter } else if (atom == prop_swap)
Peter {
Peter if (val-format != 8 || val-type != XA_INTEGER || val-size
!= 1)
Peter +
Peter return BadMatch;
Why the extra empty line in the middle of the conditional?
--
Bye, Peter Korsgaard
Peter == Peter Hutterer peter.hutte...@who-t.net writes:
Peter On Tue, May 24, 2011 at 09:44:05AM +0200, Peter Korsgaard wrote:
Some touchscreens (like the Lumio crystaltouch in single touch mode) send
BTN_LEFT rather than BTN_TOUCH:
Peter merged, thanks.
Thanks.
Peter one more thing
.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
work very well. We already internally
translate BTN_TOUCH as BTN_LEFT, so accept this kind of devices as
touchscreens by checking for devices with absolute X/Y and NO relative X/Y
axes.
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
src/evdev.c |6 --
1 files changed, 4 insertions
Tissoires benjamin.tissoi...@enac.fr
Chase specifically. He's been writing the generic USB HID multitouch
Chase driver, and he would know how to quirk things to work for your
Chase device.
Thanks. I'm already working with Benjamin to get the multitouch part
working.
--
Bye, Peter Korsgaard
of the things I'd like to have in ABI 14/server
Peter 1.12 are the proper driver hooks to change devices on-the-fly.
That sounds good.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info
Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 1
Device Status: 0x0001
Self Powered
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
in this case, its really best to get kernel side working right.
The controller uses the USB HID class, so there's no custom driver
involved atm.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg
this working with multitouch
using the hid-multitouch driver, but it would be good to atleast have it
working as a normal dumb single touch touchscreen until then.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http
feature?
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
applications figure it
out? ;)
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Peter == Peter Korsgaard jac...@sunsite.dk writes:
Hi,
Peter Ok, I missed that we're trying to solve two different use-cases.
Peter Punting a unique device ID into the properties is be quite
Peter useful, I've been struggling for a while with figuring out how
Peter to make per-device
unfortunate. Not to mention that they probably don't have
Daniel access to the devices.
Indeed. My points exactly.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org
) to be able to handle the common case of USB
devices without a unique serial number (so EVIOCGUNIQ doesn't give
anything).
The question is if we can come up with a sensible logic for choosing
between name/phys/uniq?
--
Bye, Peter Korsgaard
___
xorg-devel
unplug and replug a device
while the system is active, but it doesn't help getting the same
settings applied the next day when you boot your system again.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
. Then gnome-settings-daemon can look
Dan at the combination of DISPLAY hostname and Device UID to know
Dan which cached settings to grab.
What is the use case about 'Device Node'? Purely informational like I
mentioned above, or is there another need for it?
--
Bye, Peter Korsgaard
E.G. use something like usb-:00:1d.1-1/input0 rather than
/dev/input/event14.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Since 59056e656c64 (Remove the reopen timer logic) from last year,
EvdevCacheCompare() is only used for caching ioctl values and not for
comparing, so remove the unused compare logic and rename the function
to EvdevCache().
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
src/evdev.c | 66
of course - It seems like I forgot to ammend the commit after
I changed that - Will resend.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg
Since 59056e656c64 (Remove the reopen timer logic) from last year,
EvdevCacheCompare() is only used for caching ioctl values and not for
comparing, so remove the unused compare logic and rename the function
to EvdevCache().
Signed-off-by: Peter Korsgaard jac...@sunsite.dk
---
- Fix stupid typo
-by: Peter Korsgaard peter.korsga...@barco.com
PH thanks, I've finally had time to merge and test this. It's in my tree now,
PH I'll get it pulled by keith asap.
Great, thanks!
--
Bye, Peter Korsgaard
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is
privileged
is probably the best code
PH to look at and steal the approach.
Yes, I'll try to find time to work on this (and the device node property
stuff) this weekend.
--
Bye, Peter Korsgaard
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is
privileged and confidential
are interesting if you want an absolue input device to
span multiple screens for some kind of video wall with touchscreen
setup?
All in all, I would prefer to not hardcode any policy here in the
server. Strange values doesn't really harm us.
--
Bye, Peter Korsgaard
, the other static ones have lowercase first letters, so
Peter transformAbsolute is preferable here.
Ok, will fix and resend.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http
simon.t...@gmx.de
Thanks!
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Peter == Peter Korsgaard jac...@sunsite.dk writes:
Hi,
Really? That sounds like a bug in valgrind then. EVIOCGPHYS is correctly
marked as an input ioctl (_IOC(_IOC_READ, 'E', 0x07, len)), so it should
know that phys contains valid data after the ioctl.
But I can certainly add
can be handled.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
This is equivalent to the evdev patch sent earlier:
http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/7336
But moved into the server as requested as requested by Simon and Peter,
so it's available for all input
transform
on relative devices after they are converted to absolute coordinates,
E.G. after moveRelative().
Unless I'm missing something?
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Peter == Peter Korsgaard peter.korsga...@barco.com writes:
Peter xinput ids are not guaranteed to be stable between reboots (or hotplugs)
Peter /* All devices the evdev driver has allocated and knows about.
Peter @@ -2463,6 +2464,17 @@ EvdevInitProperty(DeviceIntPtr dev)
Peter
setups).
EVIOCGPHYS is used rather than E.G. the device node or sysfs path,
as it is (supposed to be) unique, simple to access and the remaining
information can be retrieved through /proc/bus/input/devices, which
doesn't require any special privileges.
Signed-off-by: Peter Korsgaard peter.korsga
Add Device Node xinput property containing the device node path to
all input devices with a device property. This is useful to figure out
the relation between xinput ids and kernel devices.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
As requested by Peter Hutterer during
Peter == Peter Korsgaard peter.korsga...@barco.com writes:
Peter Add Device Node xinput property containing the device node path to
Peter all input devices with a device property. This is useful to figure out
Ehhm, make that 'with a Device option' instead. -ENOCOFFE.
--
Bye, Peter Korsgaard
can be handled.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
This is equivalent to the evdev patch sent earlier:
http://thread.gmane.org/gmane.comp.freedesktop.xorg.devel/7336
But moved into the server as requested as requested by Simon and Peter,
so it's available for all input
Keith == Keith Packard kei...@keithp.com writes:
Keith On Wed, 5 May 2010 17:54:07 +0200, Peter Korsgaard
peter.korsga...@barco.com wrote:
+
+/* 3x3 coordinate transformation matrix for abs devs in row major
order */
+float transform[9];
Keith Please use a struct
setups).
EVIOCGPHYS is used rather than E.G. the device node or sysfs path,
as it is (supposed to be) unique, simple to access and the remaining
information can be retrieved through /proc/bus/input/devices, which
doesn't require any special privileges.
Signed-off-by: Peter Korsgaard peter.korsga
) - And the
structure is initialized to zero before, so it should be fine.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
expect it would have to
copy 256 bytes from somewhere to initialize unless gcc is clever.
.. Which it is, it ends up doing a rep stos loop - Which adds something
like 10-15 bytes.
I'll add the initializer and resend.
--
Bye, Peter Korsgaard
___
xorg
to this issue, though. It seems you could
Dan carry the driver specific property for now until a server level
Dan solution could be built up.
True.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org
setups).
EVIOCGPHYS is used rather than E.G. the device node or sysfs path,
as it is (supposed to be) unique, simple to access and the remaining
information can be retrieved through /proc/bus/input/devices, which
doesn't require any special privileges.
Signed-off-by: Peter Korsgaard peter.korsga
Oliver == Oliver McFadden oliver.mcfad...@nokia.com writes:
Hi,
Oliver Everything else looks fine; just the leaked storage issue.
Great, can I add your Acked-by then when I resend?
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org
), but I have left them for now.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
Acked-by: Oliver McFadden oliver.mcfad...@nokia.com
---
Changes since V1:
- Add missing xfree() noticed by Oliver
include/evdev-properties.h |7 ++
man/evdev.man | 13
src/evdev.c
they might be using.
Thanks for your input.
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
), but I have left them for now.
Signed-off-by: Peter Korsgaard peter.korsga...@barco.com
---
include/evdev-properties.h |7 ++
man/evdev.man | 13
src/evdev.c| 138 +++-
src/evdev.h|2 +
4 files
with this fixed and anything
else you find.
Oliver I'll apply the patch locally and do a full analysis after my
Oliver coffee. :-)
Great, thanks!
--
Bye, Peter Korsgaard
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives
48 matches
Mail list logo
