On 05.07.2012 23:35, Chase Douglas wrote:
If you aren't receiving a TouchEnd event, then there is something wrong.
I am receiving the TouchEnd, but it doesn't update the core state the
way it should.
The patch you are reverting is needed to fix a different bug. If you can
reproduce the issue
Hi Chase,
thank you for looking into this, and working towards a solution.
Is the patch you referenced intended as a replacement for both my
patches? Working with the touch screen alone, things work out fairly
well. But if I also use a mouse, then the lack of a TOUCH_END event
still causes the
With that patch by Chase, I also wonder what would happen if two touch
devices were used simultaneously.
When I both touch my screen and click my conventional mouse button, I
get two button events, but the state is the bitwise or of both, so the
second click will be pressed button 1 while button
** Patch added: Suppress touch state for emulated ButtonPress (from c#19)
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1015183/+attachment/3213240/+files/lp1015183e.patch
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to
Cédric, I attached the patch, after copy paste from gmane. But it
applies all right, at least to the xorg-server-1.12.1.902-1ubuntu1
currently in quantal. For precise, some adjustments are required.
I updated https://launchpad.net/~gagern/+archive/ppa to provide fixed
versions of the latest
Hi Cédric,
Although this took a little while longer, the amd packages have been
built successfully by now, and are available from my ppa.
I have the impression that your problems manifest in cases when some
application is listening to the higher level touch interfaces,
presumably using XInput.
I have a patch for the second issue of the mouse state during replay.
Will attach it here shortly. I'm currently trying to get this to my PPA,
for quantal first and for precise afterwards.
Editing the change log, I found that the removal of the TOUCH_END is not
part of the orig tarball, but comes
One aspect of those patches, the removal of TOUCH_END events, breaks
emulated pointer core mouse event state for me. See bug #1015183 for
discussion.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in Ubuntu.
** Patch added: Reverse commit which removed TOUCH_END
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1015183/+attachment/3205761/+files/lp1015183c.patch
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in Ubuntu.
** Patch added: Fix state when replaying event history
https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1015183/+attachment/3205762/+files/lp1015183d.patch
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in Ubuntu.
OK, here are the two patches which I currently use to get a working core
pointer from my touch screen. I've included them in packages available
from https://launchpad.net/~gagern/+archive/ppa for precise and quantal,
so feel free to use those to give things a try.
--
You received this bug
As the core pointer button state appears to be exclusively maintained
inside the x server core, the evdev driver is blameless.
** Changed in: xserver-xorg-input-evdev (Ubuntu)
Status: Confirmed = Invalid
--
You received this bug notification because you are a member of Ubuntu-X,
which is
OK, I bvelieve I've identified the main problem here:
http://cgit.freedesktop.org/xorg/xserver/commit/?id=a986f2f30cbe2a00e72ded7315c4951d7703e549
http://anonscm.debian.org/gitweb/?p=pkg-xorg/xserver/xorg-server.git;a=commitdiff;h=96d8df5bc9d400d55830b23afe5525b222f8dfc7
Due to that commit, the
OK, I believe I now have a good idea as to why the first ButtonPress in
xev has state 0x100. This appears to be due to an TouchOwnership event.
If ownership changes, such an event is inserted into the queue, so it
will always be processed after the BeginTouch event. I wonder how much
later it
Similar behaviour, but not entirely the same: I do receive press events.
The incorrect status is the same, though.
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in Ubuntu.
https://bugs.launchpad.net/bugs/1015183
Title:
** Tags added: touch
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xorg-server in Ubuntu.
https://bugs.launchpad.net/bugs/1015183
Title:
Inconsistent mouse events for Acer T231H multitouch monitor
To manage notifications about this bug go
I had hoped that backing
http://cgit.freedesktop.org/xorg/xserver/commit/?id=634b0da9a83076d0e9e0fc44dc5dc77b0c368bc1
out of the xorg server core code base might be enough to solve this, but
if I do so, core events never have any buttons set in their state, so
that is not a solution. Nevertheless,
Public bug reported:
I already submitted this at http://askubuntu.com/questions/153043/ but
decided to update to the latest development snapshot in order to give
that a try and write a proper bug report if the issue persists. It does
persist.
My setup is a quantal alpha 1, just upgraded from
--
You received this bug notification because you are a member of Ubuntu-X,
which is subscribed to xserver-xorg-input-evdev in Ubuntu.
https://bugs.launchpad.net/bugs/1015183
Title:
Inconsistent mouse events for Acer T231H multitouch monitor
To manage notifications about this bug go to:
NicoInattendu wrote:
I have the same issue on imac 24on karmic , with setting up a french
keyboard.
The problem apperas on karmic, noi problem on jaunty
Seems to be a bug in my fix: The french layout only has layout variants
extended and nodeadkeys, not basic, and as I defined mac to be
an
RedVivi schrieb:
I encountered the same problem with my integrated MacBookPro keyboard.
What version of Ubuntu? Have you tried with Karmic?
Have you had a look at your ~/.xsession-errors file, to check whether
there are any messages there related to keyboard layout configuration?
--
Error
Doesn't work out of the box for me on current Karmic Beta, as Jim Rorie
claims. It used to work on Intrepid with some additional packages from
the Mactel Support PPA, but I deliberately dropped all PPA packages
after updating to Karmic, and even moved the fdi file I had created on
Intrepid. So my
Unfortunately the bcm5974-dkms PPA module is delivered as full text
source, not as a patch against some underlying kernel source. So when
comparing that file to the one in the current kernel, and as I don't
know the common ancestor, I don't know which modifications were
introduced in the kernel
Stupid me: it's the Gnome settings which disabled taps and stuff like
that. I just found out that with my fdi file in place, taps worked all
right in the gdm login screen, but failed once the session was started.
I found the corresponding settings in System / Settings / Mouse /
Touchpad.
So I
I'll try. The current docs describe how you should place a file in
/etc/hal/fdi/policy/ in order to enable tapping and two-finger scrolling
and such stuff. While this is still true for the initial settings of the
X server, once a user logs in, gnome-settings-daemon overwrites these
initial
Jim Rorie wrote:
Ok, If I understand this correctly, you are saying that the hal
configuration file is only used for X. Gnome is controlled through
gnome-settings-demon and most of the settings are changed through gconf
or menu. You are not sure about KDE.
Correct.
Synclient controls
So let me get this right: you're now working with a USB keyboard plugged into
your MacBook Pro?
Is it a Mac keyboard, or some other, more PCish keybord? If the latter, then
Generic is most definitely the way to go, I'd say.
When you claim that a Generic 102 keyboard was the only way, have you
OK, now gladly disregarding VB and your external keyboard. My advice is to
1. change keyboard layout from USA Mac to USA and
2. change keyboard model from Generic to Apple/MacBook/MacBook Pro.
Order is relevant if you want to avoid error messages in between.
If that works for you, then bug 327963
Bryce, did you approach upsream, as your comment 5 indicates? What's
current status there? Do you have a URL for a bug report, mailing list
thread or similar? Recent comments on bug #67188 indicate that there is
still a lot of confustion caused by this bug here, so a fix would be
great, maybe even
spbrereton, if what you experience is in fact bug #327963, then I
believe that you should set the MODEL to something mac (e.g.
macintosh_vndr/ch) and the LAYOUT to a variant not mentioning mac
(e.g. de, not de_mac).
The reason is that the layout files for mac models simply don't mention
any
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
raketenman wrote:
Error:No Symbols named de_mac in the include file
macintosh_vndr/ch
Same as my bug #327963, I guess.
You can either have a Macintosh Swiss keyboard model with a German
layout, or you can have a generic keyboard model
Starting with Jaunty, people seeing this Error activating XKB
configuration dialog might have a look at the .xsession-errors file in
their home directory. Error messages from xkbcomp will end up there, and
others might as well. Maybe the information from these files can be used
to differentiate
32 matches
Mail list logo
