Søren Hauberg wrote:
2008/9/17 Simon Thum [EMAIL PROTECTED]:
Yeah, it does some fancy things for relative devices. Technically, you don't
have one, but you should be able to suppress it with
xset 1 1
crap. I meant
xset m 1 1
the kernel. But I'm a bit confused about one thing: the kernel
Søren Hauberg wrote:
Can I somehow force the evdev driver to only accept absolute events?
I'll see if I can find the time to look into fixing the issue, as I
guess it could be related to my problems. But like everybody else I'm
in lack of time, so I'm not sure if it'll be doable.
Adding an
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
Søren Hauberg wrote:
I'm sorry but I don't quite understand (I don't know that much about
either X, nor the kernel). But you think it would be better to solve
this in X, right? Via a special driver for touch screens? And then I
can use these 'device properties' to set the calibration
Hi Peter,
its good news you're done with that. A thing though:
-DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop)
+DeviceSetProperty(DeviceIntPtr dev, Atom property, XIPropertyValuePtr prop,
+ BOOL delete)
{
if (property ==
Peter Hutterer wrote:
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.
Looks good.
If deletable is FALSE, the prop can only be deleted by the server/a driver,
and even then only if all
Peter Hutterer wrote:
On Sun, Sep 28, 2008 at 07:26:06PM +0200, Simon Thum wrote:
rescaleValuatorAxis(int coord, AxisInfoPtr from, AxisInfoPtr to,
int defmax)
{
[...]
return (int)(((float)(coord - fmin) + 0.5f) * (tmax - tmin + 1) /
(fmax - fmin
Søren Hauberg wrote:
2008/9/29 Peter Hutterer [EMAIL PROTECTED]:
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.
Thanks! So, I guess something like the attached patch could be used to
handle the two types
Søren Hauberg wrote:
This stuff seems to only be in git. It's not in any releases, right?
Yes. It needs a current server also.
The information I seem to get from the kernel is (BTN_TOUCH, 1) when
the stylus is pressed to the screen, and (BTN_TOUCH, 0) when the
stylus is removed. When I move
Peter Hutterer wrote:
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
Keith Packard wrote:
On Wed, 2008-10-01 at 21:39 -0300, Tiago Vignatti wrote:
A mutex is needed because the X event queue is a critical region. Though
the X event queue is re-entrant, we cannot guarantee the simultaneous
processing by both main and input threads.
The input queue is
Keith Packard wrote:
On Thu, 2008-10-02 at 18:58 -0300, Tiago Vignatti wrote:
Keith Packard escreveu:
The input queue is written so that each user modifies only one of the
two pointers (head and tail). There shouldn't be any need to have a
mutex which protects both of these values together,
On Fri, 2008-10-03 at 05:57 +0300, Daniel Stone wrote:
Except if the lock is held across the entire event processing, because
we need to queue events from event processing.
I guess that's what I meant with guaranteeing order.
That makes it more important that the mutex cover precisely the
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. But
Peter Hutterer wrote:
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.
Fine, I'll be including a header.
So based on the current implementation (the one that is in master),
Peter Hutterer wrote:
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
[EMAIL PROTECTED]:/usr/src/linux-2.6.25.9# grep EVDEV .config
CONFIG_INPUT_EVDEV=y
[EMAIL PROTECTED]:/usr/src/linux-2.6.25.9#
I imagine there's a library or header file I'm missing or maybe some
relationship I'm not understanding, but I'm not sure which.
I'm not sure how slackware works
Peter Hutterer wrote:
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.
Fine. I think prop namespaces also could mitigate the problem, e.g.
driver.* Any plans for this?
Let's see if that works. We
Peter Hutterer wrote:
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.
Ok with me, but for the protocol: I stored them as floats mainly because
I store them reciprocal (to save cycles).
E.g. a deceleartion of
Florian Echtler wrote:
What would be the easiest way to achieve this? I guess it might be
possible using the new Xinput, but I was hoping that there might also be
a solution using Udev or hotplug?
That's the case. Dropping input devices from xorg.conf may be enough to
get hotplug working. Then,
Søren Hauberg wrote:
2008/10/24 Peter Hutterer [EMAIL PROTECTED]:
Hmm, yeah then I don't see an alternative to double scaling. But, hey,
as long as it only happens on touch screens then I think it'll be
okay, as it doesn't happen on ordinary devices.
May may want to try if you can avoid
Søren Hauberg wrote:
issue is keeping the code fairly clean. I imagine that the solution
you suggest will be fairly complicated, in which case I don't think it
would be worth the slight performance gain. But perhaps my priorities
aren't in place...
Well, the issue is precision which is
Tiago Vignatti wrote:
http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
Does we have this kind of thing in C libraries? It would be useful.
If I got it right, that's posix + pthreads functionality specialized for
an amtel platform. So in general, yes.
Matthieu Herrb wrote:
Simon Thum wrote:
Tiago Vignatti wrote:
http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html
Does we have this kind of thing in C libraries? It would be useful.
If I got it right, that's posix + pthreads functionality specialized for
an amtel platform
Gene Heskett wrote:
But its not that simple either, cuz when running the radeon driver, I get
random screen blanking for 1-10 seconds at a time, and for a change it
doesn't seem to be tied to the time of day since its doing it right now and
it is 10 pm.
I'm experiencing the exact same
Jeremy Huddleston wrote:
-unsigned int oldtail = miEventQueue.tail, newtail;
+unsigned int oldtail = miEventQueue.tail;
All fine, but is there a specific reason to remove newtail? Not that I'd
expect this to save more than one or two cycles on any platform...
Alex Deucher wrote:
On Thu, Nov 13, 2008 at 7:54 AM, Simon Thum [EMAIL PROTECTED] wrote:
Gene Heskett wrote:
But its not that simple either, cuz when running the radeon driver, I get
random screen blanking for 1-10 seconds at a time, and for a change it
doesn't seem to be tied to the time
Hello people,
I'm trying to get some consensus about floats on the wire. I cc'ed some
who spoke about the issue on the list in a non-exhaustive search.
Recap: Peter and I want to transfer floats in input properties, see there:
http://lists.freedesktop.org/archives/xorg/2008-December/041647.html
Walter Harms wrote:
if floats are realy needed i would go with an already established like XDR
it is already in glibc and it is a defined RFC.
Well, XDR simply states to use the IEEE representation. So I take this
as one more vote for IEEE.
At the XDR level, there seems to be an incompatibility
On XDS 08, Keith suggested simply putting them on the wire. That is,
require IEEE756 32 bit and account for endianness.
GLX already uses both 32 and 64 bit IEEE floats on the wire, so I don't
see any reason to use something different here.
I'd like to add floats to the render protocol as
Hi Peter,
some rants from me:
┌───
XIDeviceHierarchyEvent:
GENERICEVENTDATA
flags: SETofHIERARCHYMASK
ndevices: CARD16
───
devices:LISTofINT16
└───
Peter Hutterer wrote:
patches welcome :)
Here y'r. :)
From e25f0f7c38c9f5d5cfab4a20fe42ee5cbf38d012 Mon Sep 17 00:00:00 2001
From: Simon Thum simon.t...@gmx.de
Date: Fri, 23 Jan 2009 11:39:56 +0100
Subject: [PATCH] xinput: create well-known atoms on demand, rather than preinit
them
---
Xi
Hi Peter,
looks pretty good to me.
One tiny nit however: E.g. in eventconvert.c there are switch statements
which go like
switch(EventType){
...big list of labels for one thing...: do it; break;
}
So essentially, I guess, you're checking for some commonality, or
property. Centralizing such
Peter Hutterer wrote:
FP1616
Fixed point decimal in 16.16 format as 32 bit integer. The client is
required to convert to 16.16 decimal format.
Maybe it's just me, but I don't really get what 16.16 decimal format
means.
┌───
XIChangeDeviceHierarchy
Peter Hutterer wrote:
Thanks for the comments. All your suggestions have been added, but I'll
refrain from commenting on them much (the spec has to work on it's own
eventually).
No prob. Some details follow though.
FP1616
-Fixed point decimal in 16.16 format as 32 bit integer. The
Hello,
I just had my LCD tell me something like the mode should not exceed
1280x1...@75. This happened directly after starting X, and it was the
only occurrence this year, so nothing serious. However, I killed X,
restarted it and diffed the logs:
(II) RADEON(0): [agp] Ring mapped at 0xb7b2f000
Hi,
I've just rebuilt my system's ati driver, and now it's missing the
'coherent_mode' RandR prop.
This might be correct, as I only abused this prop to reinit stuff until
my display stopped showing blackouts (happens from time to time, so this
saves me restarting xorg).
In case this is
Soeren Sandmann wrote:
Simon Thum simon.t...@gmx.de writes:
However, when you implement super sampling with respect to gamma, the
quality loss drops to nearly zero. I'd say typically you need no more
strange higher quality filters when that's done.
Even a simple non-gamma-correct
Pedro Izecksohn wrote:
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
Same here, on my local system (gentoo + X11 overlay). In my git tree it
gives a good-looking -I arg.
Though I never had problems building anything.
Simon Thum wrote:
Pedro Izecksohn wrote:
pkg-config --cflags xproto
prints a line-feed only and keysymdef.h exists in my system and it is in
the right place.
Same here, on my local system (gentoo + X11 overlay). In my git tree it
gives a good-looking -I arg.
Sorry for the noise. I haven't
Bill Crawford wrote:
In theory a lot of them shouldn't need to, because they're installed in a
subdirectory of /usr/include, and you're intended to include
libfoo/blah.h ...
I guessed that also, but couldn' get it nailed down. Anyway, it looks
more like the OP's script is broken.
Pedro Izecksohn wrote:
On 2/24/09, Simon Thum simon.t...@gmx.de wrote:
Pedro Izecksohn wrote:
Where it may be found?
Nowhere, AFAIK.
You may want to know this: http://bugs.gentoo.org/show_bug.cgi?id=158476
First off, you need to use reply-all. It's an incident I saw this.
Let see if I
Peter Hutterer wrote:
XML is merely a container format. It doesn't solve our actual problem - what
information to send to the client.
[...]
We're in pretty unchartered territory, with much of the UI needing to change
anyway to accommodate for all this. Once the UI changes, the information need
Carl Karsten wrote:
http://dpaste.com/1931/
xorg finds and uses the touchscreen - good.
I need to set min/Max X/Y values - I am lost on how to do that. the #ed out
parts either have 0 effect or disable it - mouse doesn't move when I touch.
#Option MinX 4100
#Option
Dirk wrote:
I was referring to reading /many/ manuals as a relic of the nineties.
Oh, I got that, I just used it as a starter :)
I'll try this on another machine as soon as it is in debian/unstable (if
not already)... It would be great it this works and can't be overriden
by anything.
If you
Peter Hutterer wrote:
yeah, of course. sorry. what I meant was that the value x is sent as x * (1
16). A little test program for random values between 0 and 0x showed an
average rounding error of 0x08.
I can't judge whether that is good or bad :)
IMO for the protocol, definition is
Ben Gamari wrote:
On 03/11/2009 11:28 AM, Simon Thum wrote:
lshal | grep -10 x11_driver
might be valuable.
Your wish is my command:
info.callouts.add = {'hal-acl-tool --add-device'} (string list)
...
That an awful lot. on my system, only keyboard and pointer are listed.
Try booting
Ben Gamari wrote:
be too difficult to implement. Am I wrong? If not, I could potentially
take a stab at it.
Oh, I overlooked that one earlier. In the docs to ptr accel I've
described how to detect whether the server is configured to do
predictable pointer accel. The job would be defeating
Dan Nicholson wrote:
info.callouts.add = {'hal-acl-tool --add-device'} (string list)
...
That an awful lot. on my system, only keyboard and pointer are listed.
Try booting an older kernel, upgrading HAL, throw out any home-brew HAL
fdi's or go to the HAL list.
No, I think that's typical
James Cloos wrote:
The Video Bus input device is a keyboard. Mine is:
...
So, if one wants to handle those keys via X, evdev needs to read that
input device.
Thanks! I almost had managed to spend a whole day without learning
something new...
Cheers,
Simon
Halim Issa wrote:
grep: /usr/lib/libxcb-xlib.la: No such file or directory
/bin/sed: can't read /usr/lib/libxcb-xlib.la: No such file or directory
libtool: link: `/usr/lib/libxcb-xlib.la' is not a valid libtool archive
Possibly, this is biting you:
http://bugs.gentoo.org/show_bug.cgi?id=158476
Halim Issa wrote:
Would I be correct to assume that the best way to work around this is to
downgrade while waiting for these issues to stabilize upstream in the next
few months?
Depends on how whacky you want to go. E.g. on LSF/non-production I'd
give remi's script (see bug) a try. Worked
Bill Crawford wrote:
included on the command line at link time. Libtool sort of abstracts this,
but
to do so it needs to keep track of what those dependencies are, and does so
by
storing them in this .la file.
Thanks for the explanation. What baffles me is that AFAICT this
introduces a
Jeremy C. Reed wrote:
On Wed, 18 Mar 2009, Peter Hutterer wrote:
I think in 1.4, xf86OSMouseInit was still in the server, so maybe
there's some conflicts there.
That sounds like that was it. Maybe the xf86-input-mouse configure should
check for xorg-server = 1.4.99.something instead of =
I did a quick sysprof test while switching desktops, and it looks like
it's all in memcpy:
miClearToBackground 0.00 77.45
miPaintWindow 0.00 77.45
ValidateGC
Hi,
I'm bitten by this issue too and I'm somewhat lost with this. The patch
has not yet been applied or commented on xorg, so I just want to make
sure it's seen.
8yrgr4dkp...@dyweni.com wrote:
Just noticed that I created the reverse patch. Here to correct one.
Hey Everyone,
I found a
Rémi Cardona wrote:
Le 27/03/2009 19:55, Simon Thum a écrit :
Hi,
I'm bitten by this issue too and I'm somewhat lost with this. The patch
has not yet been applied or commented on xorg, so I just want to make
sure it's seen.
Then render.h also needs something like this...
To quote from
Tuomo Valkonen wrote:
The only problem with core fonts is the blur-fascist elite
not bothering to fix UTF-8 fontset support, so there you have
some problems.
If transporting visual information that would otherwise go lost is
blurring, then I'm probably not from this world. The implementation
This cannot be deduced from that line. You need to review your math.
On Wednesday 08 April 2009 22:52:12 Thomas Dickey wrote:
Behdad's comment doesn't make sense in English.
(Perhaps someone can help Behdad with that - or else explain to him
what API-stable might mean).
It makes perfect
Alan Coopersmith wrote:
Is there any reason we should have two forks of this? Which one
do most distros ship?
On gentoo:
[I] x11-apps/luit
[...]
Homepage:http://xorg.freedesktop.org/
Not a proof, though.
___
xorg mailing list
Hi,
you may want to read this:
http://www.x.org/wiki/Development/Documentation/PointerAcceleration
It is geared towards development, but also contains a lot of end-user
info as well.
with a constant acceleration (e.g. for gaming)? Something like
I'm not sure what you mean by 'constant
Harald Dunkel wrote:
Sorry, but I do want to skip pixels (for gaming only, as written
before). I understand that somebody overloaded (abused?)
threshold = 0 to provide a completely different acceleration
characteristic. I would like to have the classic profile with
a simple characteristic and
Florian Echtler wrote:
However, the second one (controlled by touchpad) reports values in the
range (1472,1408) to (5472,4448). This is also reported in the Xorg.log
by the synaptics driver. How can I map these to screen coordinates? As
the pointer still moves in screen coordinates, the
Peter Hutterer wrote:
On Sat, Apr 18, 2009 at 10:54:31AM +0200, Florian Echtler wrote:
However, the second one (controlled by touchpad) reports values in the
range (1472,1408) to (5472,4448). This is also reported in the Xorg.log
by the synaptics driver. How can I map these to screen
Peter Hutterer wrote:
relative to the window's origin but in the screen coordinate system.
so if the window is on 100/100, a device on root 101/101 has event 1/1,
even if the valuator state is e.g. 7202/2381 (valuators are in device
coordinates).
Thanks for the clarification.
Cheers,
Damien Mir wrote:
Hello,
I recently installed Opensuse 11.1 on a HP Pavilion dv8000 ( with XPRESS
200M graphics ), shipped with Xorg 7.4
(--) RADEON(0): Chipset: ATI Radeon XPRESS 200M 5955 (PCIE) (ChipID =
0x5955)
I am experiencing some kind of slow 2D performance, never seen before on
Evgeny M. Zubok wrote:
I have S3 Trio64V2 with VBE 1.2 and I want to add the possibility of
display autodetection via DDC to s3 driver. There is two ways to deal
with DDC: (i) VESA BIOS Extension and (ii) directly from videochip's DDC
registers. The later method currently is impossible to
Christian Beier wrote:
Hi there,
with the merge of xi2 coming next week, I wonder what the status of
XTest with xi2 is. Right now, XTest still pretty much looks like XI
1.x, with Device*'s instead of devive ids
(http://cgit.freedesktop.org/xorg/proto/xextproto/tree/XTest.h).
Looking at the
Peter Hutterer wrote:
The protocol only cares about the device id, so to make XTest XI2 aware, all
that's needed is some libXtst functions that take an id directly instead of
the XDevice*. So it's a pure client-side change in the library, feel free to
send me the patch :)
I wonder if one
Peter Hutterer wrote:
On Fri, May 29, 2009 at 03:42:02PM +0200, Simon Thum wrote:
I wonder if one couldn't just do a Xi1 XOpenDevice() to 'convert'
Id-Device* ? Any known reasons?
I'm not sure I understand what you mean, but
- XOpenDevice() is an XI 1 call and I really encourage
of RemoveDevice(). Daniel, is there a specific reason to use RD
and not DIDR?
Cheers,
Simon
From d2c7f41cc2564b155a285d10f404818410b92e3c Mon Sep 17 00:00:00 2001
From: Simon Thum simon.t...@gmx.de
Date: Fri, 5 Jun 2009 19:14:48 +0200
Subject: [PATCH] config: adapt to Xi2 changes
---
config/dbus.c |2
Peter Hutterer wrote:
this code hasn't been touched for ages (it's even disabled by default).
hal.c came after this code, so the use of RemoveDevice is more legacy than
anything else.
Have you tried DIDR? Does it work fine? If so I'll just amend your patch
before pushing.
Not really tried
jspran...@awlship.com wrote:
Trying to build Kdrive and I receiving the following errors:
kinput.c: In function ‘KdEnableInput’:
kinput.c:340: warning: passing argument 1 of ‘NoticeEventTime’ from
incompatible pointer type
kinput.c: In function ‘KdQueueEvent’:
kinput.c:1675: warning:
Asbjørn Sannes wrote:
But for Evdev Axis Calibration I have not found anything that works ..
Any hints and suggestions are welcome :)
One could probably do a patch which adds property manipulation to
config/hal, but it didn't surface yet.
I remember to have heard hal can be configured to
Peter Hutterer wrote:
On Sat, Jul 04, 2009 at 02:32:09PM +0200, Simon Thum wrote:
Asbjørn Sannes wrote:
But for Evdev Axis Calibration I have not found anything that works ..
Any hints and suggestions are welcome :)
One could probably do a patch which adds property manipulation to
config
Michel Dänzer wrote:
On Fri, 2009-07-10 at 08:51 -0700, Sebastian Glita wrote:
Xorg: pixman-region.c:372: pixman_region_copy: Assertion
`pixman_region_selfcheck (src)' failed.
See http://bugs.freedesktop.org/show_bug.cgi?id=22642 .
Thanks for the pointer! I started rebuilding half my system
Florian Echtler wrote:
Hello everyone,
I've recently written an input event driver for a touchscreen, and it's
working out-of-the box with the evdev driver. However, the scaling is a
bit off, so I'd like to do a four-point calibration and set the Evdev
Axis Calibration property accordingly.
Peter Hutterer wrote:
XI 1 gives you access to the valuators as well, so this should work in
principle if you register for DeviceButtonPress and friends.
Ok, big sorry if I'm wrong, but to clarify: untranslated valuators are
stored in valuators.data_raw, which is picked up solely by
Harald Braumann wrote:
If it's not possible yet, are there plans to implement such
functionality in the X server? Like sending an event whenever the
pointer stops?
Well, X is in pretty much the same situation here; it just knows when
the mouse moves, or when it did so last time (plus something
Maybe different ~/.fonts.config?
Comparing outputs of fc-list may also help.
Giacomo wrote:
Hi to all.
I am Giacomo S. from Elettra synchrotron radiation facility, Trieste, Italy.
We use to develop Qt GUIs on a kubuntu system.
The development process is as follows:
1. develop the
It's never worked ! I'm using Mandriva One 2009 with KDE 4.2.4, Somehow I had
the
impression it was something to do with the X-server because the
Ctrl-Alt-Bkspace
was also disabled. I have that fixed thanks to the list.
I'll poke around some with the settings and see if I find anything
Flittigs at PICT wrote:
Hello all, we are undergrad students trying to install and compile the
latest X release on a virtual box. We did all installation on /opt/MPX
prefix.
on doing sudo /opt/MPX/bin/X -config /../xorg.conf , the X server starts
running and screen goes blank. We also
Justin Piszcz wrote:
Solution for now as I need a working desktop:
1. Recover OS from backup before upgrade:
2. Pin kde* and xorg* so they are not upgraded anymore.
In the future/if someone from xorg can respond-- is there a fix/way to
make the semantics such that 'xset m 20/5 1' is the
Yotam Medini wrote:
+ On current Ubuntu, it is not easy to configure. The GSynapyics tool
warns (and requires(?)) settings in /etc/X11/xorg.conf
while current configuration happens under /usr/share/hal/fdi/...
I can't say that about ubuntu, but I can place stuff in /etc/hal/fdi/...
so once
Magnus Kessler wrote:
On Friday 06 November 2009, Simon Thum wrote:
Rémi Cardona wrote:
from git and completely rebuilt. And with a single command, users can
rebuild all live packages.
Would you be so kind to explain what exactly you're talking about? I'd
be highly interested...
(Last time
Alan Coopersmith wrote:
misunderstanding. (My employer on the other hand, requires us not to
automatically label everything as confidential, since that just causes people
to assume nothing really is, and destroys all value of true confidential
labels.)
I'm amazed by the sheer amount of
ZelluX wrote:
Considering such a situation, some applications are running on x window
systems and one of them, for example, a web browser has the focus. If there
comes an interrupt, such as a keyboard interrupt, and now kernel takes over
the control. My question is that what's the running
of information.
In general, is it reasonable to point to the wiki from a man page? That
one's separate if the answer is no.
Cheers,
Simon
From 84ceba932e93c0b2467be696c9878c4d9c59312b Mon Sep 17 00:00:00 2001
From: Simon Thum simon.t...@gmx.de
Date: Sun, 18 Oct 2009 15:10:56 +0200
Subject: [PATCH 1/2
Peter Hutterer wrote:
On Thu, Dec 10, 2009 at 03:13:30PM -0800, Alan Coopersmith wrote:
Peter Hutterer wrote:
On Thu, Dec 10, 2009 at 10:24:20PM +0100, Simon Thum wrote:
+has more detials. For X.org 1.7
^^^ typo ^^ X.Org X Server 1.7
I missed that one. Our canonical writing
Ross Vandegrift wrote:
When I installed xinput, the first thing I did was look at the man
page. But it's nearly useless - all it really does is list how the
commands map onto API functions. I don't know the XInput API, so most
of it doesn't mean anything to me.
I take it the man page is a
Resending to include philip as xinput maintainer. xset doesn't have a
dedicated maintainer. Alan?
Peter Hutterer wrote:
On Thu, Dec 10, 2009 at 03:13:30PM -0800, Alan Coopersmith wrote:
Peter Hutterer wrote:
On Thu, Dec 10, 2009 at 10:24:20PM +0100, Simon Thum wrote:
+has more detials
Justin Piszcz wrote:
On Fri, 18 Dec 2009, Lorenz Ruhmann wrote:
Is there a way to exactly reproduce this old behavior with the new code?
I don't like to rely on a scheme that is kinda considered obsolete.
[..]
Yes, this is VERY annoying to me as well (all of the new acceleration
methods
Gene Heskett wrote:
I would tend to agree. With modern high resolution mice, I have often wished
I could set the gain to a below 1 condition. My mouse now uses about a 1
x1.35 area of the pad, to cover a 1680x1250 screen, so its way too fast for
this user.
I'm not sure I got it. What you
Peter Hutterer wrote:
On Sat, Dec 19, 2009 at 02:25:16PM +0100, Simon Thum wrote:
Peter Hutterer wrote:
given the two changes alan already suggested,
Reviewed-by: Peter Hutterer peter.hutte...@who-t.net
please send out the last version of these patches and I'll push them once
they're in my
Lorenz Ruhmann wrote:
After alternating between the two schemes several times and repeating
specific mouse strokes a few dozen times, I'm getting less and less
convinced that there actually is a difference. Also, considering you say
my settings are correct (I'm not using adaptive
Gene Heskett wrote:
On Saturday 19 December 2009, Simon Thum wrote:
Gene Heskett wrote:
I would tend to agree. With modern high resolution mice, I have often
wished I could set the gain to a below 1 condition. My mouse now uses
about a 1 x1.35 area of the pad, to cover a 1680x1250 screen
Keith Packard wrote:
Do we have enough info to start assigning default profiles to different
kinds of devices yet? Should we stick this in some default xorg.conf.d
fragments? Or should we stick it in the code instead?
Essentially, there is no fixed relation. I tested the 'wacom' profile
w/my
changes are bogus, I just copied around
and I seem not to have broken things.
Cheers,
Simon
From 6bdb4ab5abef8a2155df23281c4ca1268dc999ae Mon Sep 17 00:00:00 2001
From: Simon Thum simon.t...@gmx.de
Date: Tue, 5 Jan 2010 11:50:05 +0100
Subject: [PATCH 1/4] dix: rename input property for 'constant
Peter Hutterer wrote:
thanks, that woke me up. I was struggling this morning :)
always a pleasure.
I don't think this is necessary. We're nitpicking on the wording here and
given the number of languages out there there's always going to be some
ambiguity. with this patch you're breaking user
Those patches should address the issues. The rename is skipped for now.
Peter Hutterer wrote:
thanks, that woke me up. I was struggling this morning :)
On Tue, Jan 05, 2010 at 09:13:47PM +0100, Simon Thum wrote:
another round of ptr accel patches. I didn't send to the dev list to
maybe
1 - 100 of 123 matches
Mail list logo
