Bug#432613: xkb-data: virtual keys missing from evdev keycodes, breaks modifiers
On Thu, Jul 12, 2007 at 12:30:08AM +0200, Mohammed Adnène Trojette wrote: > On Wed, Jul 11, 2007, Yann Vernier wrote: > > to codes that never occur. I added similar lines to evdev: > > // Fake keycodes for virtual keys > > = 241; > > = 242; > > = 243; > > = 244; > > = 245; > > = 246; > > And now my bindings do work. In linux/input.h keycode 240 is called > > unknown and the range 241-255 are not defined. > > Please could you prepare a patch ready to be applied? It would be really > kind from you. I'll forward it upstream and try to prepare an upload > this week-end. Okay, attaching something. --- /usr/share/X11/xkb/keycodes/evdev.orig 2007-07-24 03:01:21.0 +0200 +++ /usr/share/X11/xkb/keycodes/evdev 2007-07-24 03:02:19.0 +0200 @@ -269,6 +269,14 @@ = 243; // #define KEY_DOCUMENTS 235 = 244; // #define KEY_BATTERY 236 + // Fake keycodes for virtual keys += 241; += 242; + = 243; += 244; += 245; += 246; + indicator 1 = "Caps Lock"; indicator 2 = "Num Lock"; indicator 3 = "Scroll Lock";
Bug#432613: xkb-data: virtual keys missing from evdev keycodes, breaks modifiers
Subject: xkb-data: virtual keys missing from evdev keycodes, breaks modifiers Package: xkb-data Version: 0.9-4 Severity: normal *** Please type your report below this line *** Upon switching from kbd to evdev driver, and thus from xorg to evdev keycode mappings, my window manager bindings stopped working. I eventually traced this down to a weird part of the keycode files. In keycodes/xfree86, there are mappings for seven keys including to codes that never occur. I added similar lines to evdev: // Fake keycodes for virtual keys = 241; = 242; = 243; = 244; = 245; = 246; And now my bindings do work. In linux/input.h keycode 240 is called unknown and the range 241-255 are not defined. xmodmap output with this change: xmodmap: up to 3 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x69) mod1Alt_L (0x40), Alt_L (0xf3), Meta_L (0xf4) mod2Num_Lock (0x4d) mod3 mod4Super_L (0xf5), Hyper_L (0xf6) mod5ISO_Level3_Shift (0x6c), Mode_switch (0xf1), ISO_Level3_Shift (0xf2) xmodmap output witout it: xmodmap: up to 2 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lockCaps_Lock (0x42) control Control_L (0x25), Control_R (0x69) mod1Alt_L (0x40) mod2Num_Lock (0x4d) mod3 mod4 mod5ISO_Level3_Shift (0x6c) The left logo key is mapped to Super_L and mod4, but without the fake keys that fails somehow. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=sv_SE.ISO-8859-15, LC_CTYPE=sv_SE.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#278312: xserver-xfree86: [palmax] Touchscreen packets not processed unless under high load
On Tue, 16 Jan 2007 22:52:07 +0100 Brice Goglin <[EMAIL PROTECTED]> wrote: > About 2 years ago, you reported a bug to the Debian BTS regarding > touchscreen packets being ignored under high load. Did you reproduce > this problem recently? If not, I will close this bug in the next > weeks. I rarely use that machine anymore, but if I recall correctly I did about six months ago, and had to reapply the fix when I upgraded X. It's probably easier to check the code to see if the logic error is still there (not processing a packet unless *more* data is present). I can recheck it if you want, but not today. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392498: palmax touchscreen logic bug prevents use in low loads
Package: xserver-xorg-input-palmax
Version: 1.0.0.5-2
The palmax touchscreen driver contains a bug related to
the parsing of data from the serial port. The problem
occurs when less than five bytes have been read after the
current package to be processed, a very frequent case
except when the system is under high load. The result is
that touchscreen data is discarded instead of parsed,
rendering the touchscreen unresponsive.
I have found the faulty logic and am attaching a patch
which seems to solve the problem correctly for me, though
it could probably use a second set of eyes to check for
other thinkos.
I am using a Palmax PD-1100, and with this patch applied
my touchscreen seems to work fine.
*** xserver-xorg-input-palmax-1.0.0.5/src/xf86Palmax.c Mon Feb 13 04:47:12 2006
--- xserver-xorg-input-palmax-1.0.0.5.fixed/src/xf86Palmax.cThu Oct 12
01:18:17 2006
***
*** 15,20
--- 15,23
#include "xf86Module.h"
#endif
+ #include
+ #include
+
/*
***
*
***
*** 28,34
#define DEFAULT_MAX_Y 61592
#define DEFAULT_MIN_Y 7608
! #define XI_STYLUS "TOUCHSCREEH" /* X device name for the stylus
device */
/*
--- 31,37
#define DEFAULT_MAX_Y 61592
#define DEFAULT_MIN_Y 7608
! #define XI_STYLUS "TOUCHSCREEN" /* X device name for the stylus
device */
/*
***
*** 301,307
bytes_in_packet = 0;
start_ptr = ptr;
! while (num_bytes >= report_size)
{
/*
* Skip bytes until we hit a header (FE/FF)
--- 304,310
bytes_in_packet = 0;
start_ptr = ptr;
! while (num_bytes >= report_size-bytes_in_packet)
{
/*
* Skip bytes until we hit a header (FE/FF)
Bug#243237: xlibs-data: locale.alias ineffective
Package: xlibs-data Version: 4.3.0.dfsg.1-5 Followup-For: Bug #243237 A friend hit this problem, having a debconf configured LANG variable he couldn't type our national letters in Sylpheed. xlibs-data contains a file /usr/X11R6/lib/X11/locale/locale.alias which appears to have no function: [EMAIL PROTECTED]:~$ grep sv_SE.*8859-15 /usr/X11R6/lib/X11/locale/locale.alias sv_SE.iso885915 sv_SE.ISO8859-15 [EMAIL PROTECTED] sv_SE.ISO8859-15 [EMAIL PROTECTED] sv_SE.ISO8859-15 sv_SE.iso885915:sv_SE.ISO8859-15 [EMAIL PROTECTED]: sv_SE.ISO8859-15 [EMAIL PROTECTED]: sv_SE.ISO8859-15 [EMAIL PROTECTED]:~$ [EMAIL PROTECTED] gtkfontsel Gdk-WARNING **: locale not supported by C library [EMAIL PROTECTED]:~$ LANG=sv_SE gtkfontsel [EMAIL PROTECTED]:~$ Other variants mentioned in the file also fail. sv_SE.ISO-8859-15 is not mentioned and fails, sv_SE.ISO8859-15 is accepted. Sylpheed picks horrid fonts when using that locale, but that's most likely not a xlibs problem. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.6-1-k7 Locale: LANG=sv_SE, LC_CTYPE=sv_SE -- no debconf information
