Bug#613145: xserver-xorg-input-evdev: Please add "Disable middle mouse button emulation by default." to NEWS.Debian
Package: xserver-xorg-input-evdev Version: 1:2.6.0-2 Severity: normal The default behavior for "middle mouse button emulation" was changed with upstream commit 21a2ac818e75ef918d320ce1e88b6263e68e598d, which broke my setup today when upgrading to unstable. I have an 5 button, 2 wheels, 1 key mouse, which is lacking button #3, so I prefer the emulation. See /usr/share/doc/xserver-xorg-input-evdev/changelog.gz for the full message and for a work around. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Oct 28 2008 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 1917984 Feb 5 13:14 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller: nVidia Corporation G84 [GeForce 8600 GT] (rev a1) Xorg X server configuration file status: -rw-r--r-- 1 root root 2143 Feb 13 08:50 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: --- Section "ServerLayout" Identifier "Default Layout" Screen 0 "TwinScreen" 0 0 EndSection Section "ServerFlags" # Option "DefaultServerLayout" "Default Layout" # Option "NoTrapSignals" "off" # Option "DontVTSwitch" "off" # Option "DontZap" "off" # Option "DontZoom" "off" # Option "DisableVidModeExtension" "false" # Option "AllowNonLocalXvidtune" "off" # Option "DisableModInDev" "false" # Option "AllowNonLocalModInDev" "off" # Option "AllowMouseOpenFail""false" # Option "VTinit""" # Option "VTSysReq" "off" # Option "XkbDisable""off" # Option "PC98" "false" # Option "NoPM" "false" # Option "AllowDeactivateGrabs" "off" # Option "AllowClosedownGrabs" "off" # Option "HandleSpecialKeys" "WhenNeeded" # Option "AIGLX" "off" # Option "UseDefaultFontPath""true" # Option "IgnoreABI" "false" # Option "EstimateSizesAggresively" "0" Option "BlankTime" "10"# 10 minutes Option "StandbyTime" "0" Option "SuspendTime" "30" Option "OffTime" "0" # Option "Pixmap""32" # Option "Xinerama" "0" EndSection Section "Monitor" Identifier "ECOMO 19H99" VendorName "Elsa" ModelName "ELSA ECOMO 19H99" HorizSync 30.0 - 95.0 # multisync VertRefresh 50.0 - 152.0# multisync Option "DPMS" EndSection Section "Monitor" Identifier "DELL G2410" VendorName "DELL" ModelName "DELL G2410" EndSection Section "Device" Identifier "MSI 8600" Driver "nvidia" VendorName "MSI" BoardName "GeForce 8600 GT" Option "HWCursor" "on" BusID "PCI:01:00:0" #Option "UseDisplayDevice" "DFP-1" #Option "UseDisplayDevice" "CRT-0" EndSection Section "Screen" Identifier "TwinScreen" Device "MSI 8600" Monitor"ECOMO 19H99" DefaultDepth24 Option "TwinView" "1" Option "TwinViewXineramaInfoOrder" "DFP-1 CRT-0" Option "metamodes" "CRT: 1280x1024 +1920+0, DFP: nvidia-auto-select +0+0 SubSection "Display" Depth 24 EndSubSection EndSection Section "Extensions" Option "Composite" "enable" EndSection Section "InputClass" Identifier "middle button emulation class" MatchIsPointer "on" Option "Emulate3Buttons" "on" EndSection /etc/X11/xorg.conf.d does not exist. Kernel version (/proc/version): --- Linux version 2.6.37 (pmhahn@scout) (gcc version 4.4.5 (Debian 4.4.5-10) ) #1 SMP PREEMPT Wed Jan 5 07:37:04 CET 2011 Xorg X server log files on system: -- -rw-r--r-- 1 root root 15413 Apr 24 2010 /var/log/Xorg.1.log -rw-r--r-- 1 root root 18665 Feb 13 08:28 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [15.688] X.Org X Server 1.9.4 Release Date: 2011-02-04 [15.688] X Protocol Version 11, Revision 0 [15.688] Build Operating System: Linux 2.6.32-5-amd64 x86_64 Debian [15.688] Current Operating System: Linux scout 2.6.37 #1 SMP PREEMPT Wed Jan 5 07:37:04 CET 2011 x86_64 [15.688] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.37 root=UUID=513effc1-8374-4162-8ce9-bf16f6545b4a ro quiet [15.688] Build Date: 05 February 2011 12:02:52PM [15.688] xorg-server 2:1.9.4-1 (Cyril Brulebois ) [15.688] Current version of pixman: 0.21.4 [15.688]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [
[BUG,PATCH] xorg-server
Hello!
I use Debiann/GNU Linux and have an "IBM Corp. SK-8815 Keyboard" which
exports two devices, one regular "PC 105 USB" keyboard, and an extension
for the multimedia keys and buttons to quick-start applications.
I: Bus=0003 Vendor=04b3 Product=301b Version=0110
N: Name="Lite-On Technology USB Productivity Option Keyboard( has the
hub in # 1 )"
P: Phys=usb-:00:1a.7-4.3.1/input0
S: Sysfs=/class/input/input2
U: Uniq=
H: Handlers=kbd event2
B: EV=120013
B: KEY=1 7 ff9f207a c14057ff febeffdf ffef fffe
B: MSC=10
B: LED=1f
I: Bus=0003 Vendor=04b3 Product=301b Version=0110
N: Name="Lite-On Technology USB Productivity Option Keyboard( has the
hub in # 1 )"
P: Phys=usb-:00:1a.7-4.3.1/input1
S: Sysfs=/class/input/input3
U: Uniq=
H: Handlers=kbd event3
B: EV=13
B: KEY=ff 0 200 3878 d801 e 0 0 0
B: MSC=10
The "application" buttons are reported as USB-HID-events
256 BTN_0
257 BTN_1
258 BTN_2
259 BTN_3
260 BTN_4
261 BTN_5
262 BTN_6
263 BTN_7
xserver-xorg-input-evdev receives them fine, but since they are above
(255-8), they are SILENTLY discarded and are not passed on. It woule
haven been fine if at least a message was logged somewhere, that buttons
above 255-8 are currently not supported.
xserver-xorg-input-evdev-2.0.3/src/evdev.c:267 PostKbdEventa()
xserver-xorg-input-evdev-2.0.3/src/evdev.c:145 xf86PostKeyboardEvent()
xorg-server-1.4.2/hw/xfree86/common/xf86Xinput.c:694 GetKeyboardEvents()
xorg-server-1.4.2/dix/getevents.c:380 GetKeyboardValuatorEvents()
xorg-server-1.4.2/dix/getevents.c:403
There was one bug filed and "fixed", which "rejects out-of-range keycodes":
http://article.gmane.org/gmane.linux.debian.devel.x/58539
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=443697
https://bugs.freedesktop.org/show_bug.cgi?id=12528
I have a problem with the fix for that bug:
1. The limits are hard-coded to 8 <= key_code <= 255. Isn't
curKeySyms.{min,max}KeyCode supposed to have the actual limits?
2. The range-check is too late, since map[key_code - min] is
dereferenced BEFORE the range-check. I think this only survived because
gcc is clever enouth to have reordered the assignment after the check.
Because of this I propose the following patch:
--- xorg-server-1.4.2/dix/getevents.c~ 2008-09-10 08:44:23.0 +0200
+++ xorg-server-1.4.2/dix/getevents.c 2008-09-10 09:04:46.0 +0200
@@ -409,9 +409,6 @@ GetKeyboardValuatorEvents(xEvent *events
KeySym sym;
deviceKeyButtonPointer *kbp = NULL;
-sym = map[(key_code - pDev->key->curKeySyms.minKeyCode)
- * pDev->key->curKeySyms.mapWidth];
-
if (!events)
return 0;
@@ -423,7 +420,8 @@ GetKeyboardValuatorEvents(xEvent *events
(pDev->coreEvents && !inputInfo.keyboard->key))
return 0;
-if (key_code < 8 || key_code > 255)
+if (key_code < pDev->key->curKeySyms.minKeyCode ||
+key_code > pDev->key->curKeySyms.maxKeyCode)
return 0;
if (pDev->coreEvents)
@@ -437,6 +435,9 @@ GetKeyboardValuatorEvents(xEvent *events
numEvents += (num_valuators / 6) + 1;
}
+sym = map[(key_code - pDev->key->curKeySyms.minKeyCode)
+ * pDev->key->curKeySyms.mapWidth];
+
#ifdef XKB
if (noXkbExtension)
#endif
I've test-compiled a new x-sever with this patch applied and have run it
successfully.
BYtE
Philipp
--
/ / (_)__ __ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ pmh...@titan.lahn.de
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#318660: Provides: libgl1 virtual package?
Package: nvidia-glx Version: 1.0.7676-1 Followup-For: Bug #318660 nvidia-glx (non-free) has a strage header: $ dpkg -I /var/cache/apt/archives/nvidia-glx_1.0.7676-1_i386.deb Conflicts: nvidia-glx-src Replaces: nvidia-glx-src Provides: xserver nvidia-glx does NOT provide an xserver itself, it only provides a new module/driver. Here's a list of all packages providing xserver: $ grep-available -F Provides xserver -s Package Package: vncserver Package: xserver-xorg Package: nvidia-glx Package: xserver-xorg-dbg Package: tightvncserver It instead provides an alternative libgl1: $ dpkg -c nvidia-glx_1.0.7676-1_i386.deb ... -rw-r--r-- root/root515012 2005-09-07 22:30:01 ./usr/lib/libGL.so.1.0.7676 lrwxrwxrwx root/root 0 2005-09-07 22:30:00 ./usr/lib/libGL.so.1 -> libGL.so.1.0.7676 ... libgl1 is also provided by the following packages: $ grep-available -F Provides libgl1 -s Package Package: xlibmesa-gl Package: mesag3 Package: libgl1-mesa-glide3 There's also nvidia-glx and libgl1-mesa-dri according to http://packages.debian.org/cgi-bin/search_contents.pl?word=libGL.so.1&searchmode=searchfiles&case=sensitive&version=unstable&arch=i386 $ apt-cache show xlibmesa-gl mesag3 libgl1-mesa-glide3 libgl1-mesa-dri nvidia-glx|grep ^[PRC] Package: xlibmesa-gl Replaces: libgl1, libutahglx1, xlibmesa3 (<< 4.2.1-5), xlibmesa3-gl Provides: libgl1 Conflicts: libgl1, libutahglx1, xlibmesa3 (<< 4.2.1-5), xlibmesa3-gl Package: mesag3 Replaces: libgl1 Provides: libgl1 Conflicts: mesag3-glide, mesag3-glide2, mesag3+ggi, libgl1, nvidia-glx Package: libgl1-mesa-glide3 Replaces: mesag3, libgl1 Provides: mesag3, libgl1 Conflicts: mesag3-glide, mesag3, mesag3+ggi, libgl1, nvidia-glx Package: libgl1-mesa-dri Package: nvidia-glx Should "libgl1" be a virtual package? Dependent on that, should the headers of nvidia-glx should look like: Conflicts: nvidia-glx-src, libgl1 Replaces: nvidia-glx-src, libgl1 Provides: libgl1 Similar for libgl1-mesa-dri: Conflicts: libgl1 Replaces: libgl1 Provides: libgl1 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (989, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.13-walker Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What to do about #252170
Hello! Sorry for the delay, but I was ill and work keeps me busy. On Mon, Jun 21, 2004 at 08:57:30PM +0200, Marcin Owsiany wrote: > I'm sending this message to maintainers of packages which are possibly > involved in the problem. > > Please read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252170 > > I know very little of X programming, so I have no idea which package is > "guilty" of the problem: > - xmms-xf86audio for using XStringToKeysym > - xmms for not caring about setting up Xlib thread support early enough > - xosd for setting up Xlib thread support too late > - xlib for having such and not other thread support interface > > Anyway, we need to decide how to resolve the problem. Please help. I investigates this yesterday and here are my findings: 1. xosd is multithreded using 3 threads for X11-exposure, timeout and control. 2. xosd opens its own X11 display but needs X11-Tread support, so it calls XInitThread, which is wrong, because xmms dynamically loads the library way after its first call to X11. 3. Putting an XInitThread()-call in xmms might solve this problem. But since there are other applications using libxosd, they all must also call XInitThread() before using libxosd. Not doing this will later crash the application. Therefor I see only one solution: Rewrite xosd to use only one thread for X11 calls. I'll try to do that, but I'm busy with university and my scouting activities, so it might take me some time. Before I start coding, I'll ask some questions for the new implementation: The current implementation has one thread listening for X11 exposures to redraw the display. The loop blocks using XWindowEvent(). I'm going to use select() on ConnectionNumber(x11->display). Another thread handles timeouts. Currently it directly calls X11 to hide the display. How do I best convert it to something that works with select() for inter-thread-communication()? Use a pipe()? On Linux I could get rid of that thread and use select()'s timeval to do the timeout, since Linux updates timeval to contain the remaining sleep time. But that's not portable, so for non-Linux I'll have to use gettimeofday(). Any better ideas? A third thread will control xosd (updating text, changing colors/fonts) on users request. This threads will have to also communicate with the first thread to notify it of changes. Should I use a pipe() or signal() or what else for inter-thread-communication? BYtE Philipp -- Philipp Matthias Hahn <[EMAIL PROTECTED]> GPG/PGP: 9A540E39 @ keyrings.debian.org
