Re: Anyone using a large panning desktop
On 10/14/2011 02:29 PM, Harry Putnam wrote: Is anyone here running a large panning (pannable) desktop. If so would you mind posting your combination of hardware and X related settings and versions? I saw your questions about broken panning in another mailing list, so I tried adding Virtual 2048 1024 to the Display subsection in xorg.conf the way I did years ago. I was disappointed to find that the change had no effect so I assumed that I was having the same problem you are and forgot about it. I was shocked this morning to find that simply logging in as a different user (with a fresh home directory) produces a working panning desktop! I'm running gnome 2.32.x on xorg server 1.9.5 with the proprietary nvidia drivers 173.14.31. The salient point is, obviously, that something in my usual gnome environment breaks desktop panning -- but what is it? Gnome has so many knobs to twiddle I don't even know where to start looking. Anyone else have an idea? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Shift-Backspace kills X?
I often type Shift-Backspace by mistake, and I must have been doing it since I bought my current keyboard a year ago or more. Just lately I've found that Shift-Backspace terminates my X session just the way Ctrl-Alt-Backspace did in the old days. This was an unpleasant surprise, as it's purely unintentional. I finally traced this strange behavior to a very old setting in my gnome desktop config files that effectively adds three XkbOptions: grp grp:alts_toggle terminate terminate:ctrl_alt_bksp capscaps:none I must have copy/pasted these items from somewhere a long time ago when trying to restore the old Ctrl-Alt-Backspace behavior, but I can't remember where I got them. Anyone understand how/why those old options are now being translated into to my current unwanted behavior? I'm running gentoo, which frequently updates all sorts of xorg- related packages and drivers, so it might have been any of them, dunno for sure. Any hints much appreciated :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Shift-Backspace kills X?
On 10/04/2011 09:19 AM, Octoploid wrote: walt w41ter at gmail.com writes: Just lately I've found that Shift-Backspace terminates my X session just the way Ctrl-Alt-Backspace did in the old days. Yes, I've hit the same problem. I came up with this hack in .xinitrc , which solves the issue for me: (sleep 2 xmodmap -e keycode 22 = BackSpace BackSpace BackSpace BackSpace NoSymbol NoSymbol Terminate_Server) That evidently does the same as editing /usr/share/X11/kdb/symbols/terminate (thanks for the clue Alan :) but how did you come up with that fix on your own? Are you one of the rare individuals in our solar system who really understands what that, um, stuff actually means? I've done a bit of googling on the key- code stuff in the past and finally gave up in despair of ever making sense of it. For example, why does the keycode spec include four BackSpaces and two NoSymbols? Which documentation actually explains why it's done that way? I'll read it again if you can point me to it. Many thanks for the help! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Emulate3Buttons not honored
On 07/25/2011 07:27 AM, Kevin Van Workum wrote: ... I'm trying to get my ORtek Wireless Touchpad keyboard to emulate 3 buttons... ... Note that X reports that it 'Found 3 mouse buttons', but in fact there are only 2 real buttons... Sounds like you already know more about this stuff than I do :) Just an idle observation: I have a four-button trackball mouse that xorg announces as having 9 buttons. According to xev, the buttons are 1: Left click 3: Right click 2: buttons 1 and 3 pressed at the same time 8: Left tiny-button click 9: Right tiny-button click That's all. Buttons 4-7 don't exist. Someone in this mailing list explained this numbering system to me a long time ago. Shame I can't remember it now :( Anyway, my point is that button numbering schemes can be sneaky, and you may learn something interesting if you run xev and click the buttons in random ways, maybe including double-tapping the touchpad, etc. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: evdev fails with Couldn't open mtdev device
On 07/11/2011 02:24 AM, Florian Echtler wrote: Hi everyone, I'm trying to configure a secondary X server for an auxiliary touchscreen, but I'm having some problems with the input configuration. To keep input for my main screen and the auxiliary screen separate, I'm using the following config for the secondary one: Section InputDevice Identifier mimoTouch Driver evdev Option CorePointer trueB Option Device /dev/input/event2 EndSection Have you read about the new InputClass Section? It has some advantages over the older InputDevice, including the important ability to identify devices by their plug-n-play names instead the event number. As an example, here's my input section for a non-standard mouse: #cat /etc/X11/xorg.conf.d/10-trackball.conf Section InputClass --- note the new name Identifier trackball - I made this name up MatchProduct ImExPS- important: I did not make this up Option AutoServerLayout on Option Emulate3Buttons on Option EmulateWheel on Option EmulateWheelButton 8 EndSection Note the MatchProduct keyword. Unless you have two identical input devices this product name will be unique and invariant over reboots, unlike event2. There are two places I could get the string for MatchProduct -- dmesg and #udevadm info --export-db: #dmesg|grep Logitech input: ImExPS/2 Logitech Explorer Mouse as /devices/platform/i8042/serio1/input/input4 And the corresponding (very small) section from udevadm info --export-db: P: /devices/platform/i8042/serio1/input/input4 E: UDEV_LOG=3 E: DEVPATH=/devices/platform/i8042/serio1/input/input4 E: PRODUCT=11/2/6/6d E: NAME=ImExPS/2 Logitech Explorer Mouse E: PHYS=isa0060/serio1/input0 E: PROP=0 E: EV=7 E: KEY=1f 0 0 0 0 0 0 0 0 E: REL=143 E: MODALIAS=input:b0011v0002p0006e006D-e0,1,2,k110,111,112,113,114,r0,1,6,8,amlsfw E: SUBSYSTEM=input I don't know if any of this will help solve your problem, but I'd be interested to know if any of the experts here will include it in their advice. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: arious x apps (xterm, xfontsel) don't start due to missing fonts
On 03/24/2011 02:19 PM, Shiva Persaud wrote: Hi folks, I'm having what appears to be a common problem but not of the solutions I've found on various forums and threads have worked for me. I noticed this issue after I configured my system to use the en_US.utf8 locale but it's possible that this issue existed before that change. Note that in debugging I've gone back to using having POSIX as my locale and the problem persists. I noticed then when I did a ctrl-right click xterm windows would close. I started an xterm from an xterm and ctrl-right clicked on the new xterm and saw the following error message: begin ~(245)$ xterm Warning: Cannot convert string -adobe-helvetica-bold-r-normal--*-120-*-*-*-*-iso8859-* to type FontStruct Warning: Unable to load any usable ISO8859 font I just had a font problem after a recent gentoo update, too, but I'm not sure it's the same problem. My problem was caused by a change in the way the misc.misc fonts are named, but the font.alias package doesn't contain the corresponding changes. (Perhaps a version mismatch?) Specifically, I use the 9x15 alias listed in fonts.alias: #grep 9x15 /usr/share/fonts/misc/fonts.alias 9x15 -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso8859-1 9x15bold -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso8859-1 However, fonts.dir lists those two fonts as: #grep 9x15 /usr/share/fonts/misc/fonts.dir 9x15.pcf.gz -misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1 9x15B.pcf.gz -misc-fixed-bold-r-normal--15-140-75-75-c-90-iso10646-1 Note the iso8858 changed to iso10646, so fonts.alias was pointing to a nonexistent font. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: No mouse, no keyboard in X
On 03/17/2011 07:08 PM, jazzbo wrote: walter s wrote: On 03/15/2011 06:46 PM, jazzbo wrote: The Xserver doesn't find the mouse or keyboard unless keyboard and mouse are unplugged / plugged in. The X logfile should give you some messages about input devices when the X server is starting up. When you un-plug/re-plug the devices you should see more log messages. Also check dmesg to see if the kernel is finding the mouse and keyboard during boot. I found this in the log. (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. (WW) Disabling Mouse0 (WW) Disabling Keyboard0 You probably still have the mouse and kbd drivers in your xorg.conf something like this:: Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse You should delete those InputDevice sections completely because newer Xorg servers don't need them. The evdev input driver finds the mouse and keyboard without any configuration. You can remove the mouse and kbd drivers from your machine, too, as they've been replaced by evdev. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: No mouse, no keyboard in X
On 03/15/2011 06:46 PM, jazzbo wrote: The Xserver doesn't find the mouse or keyboard unless keyboard and mouse are unplugged / plugged in. The X logfile should give you some messages about input devices when the X server is starting up. When you un-plug/re-plug the devices you should see more log messages. Also check dmesg to see if the kernel is finding the mouse and keyboard during boot. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: HTML colouring in xedit
On 01/13/2011 07:06 AM, Johannes Truschnigg wrote: just suck it up and import CACert's class1 and class3 roots into your trusted certificate store Thank you! I would have done that ages ago if only you had mentioned it earlier :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [xorg-server-1.9.2.902] How to set EmulateWheelButton with no hal? [SOLVED]
On 12/26/2010 08:27 AM, walt wrote: On 12/25/2010 10:31 PM, Peter Hutterer wrote: http://who-t.blogspot.com/2010/01/new-configuration-world-order.html Thanks Peter. I got the emulate wheel working again with this: $cat /etc/X11/xorg.conf.d/10-trackball.conf Section InputClass Identifier pointer MatchProduct ImExPS Driver evdev --- I DELETED THIS LINE Option AutoServerLayout on Option Emulate3Buttons on Option EmulateWheel on Option EmulateWheelButton 8 EndSection Even though the mouse works normally, these lines at the end of Xorg.log make me suspect that something is still not right: [ 5223.204] (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/mouse0 [ 5223.204] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 5223.204] (II) UnloadModule: evdev [ 5223.204] (EE) PreInit returned NULL for ImExPS/2 Logitech Explorer Mouse Are those errors something to worry about? I tried deleted the Driver evdev line because evdev had already discovered the mouse before reading my new .conf file. Now the last line of Xorg.log is: [ 489.498] (II) No input driver/identifier specified (ignoring) I don't know if I've found the truly correct way to configure the mouse, but I'm happier with one warning than with two error messages :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [xorg-server-1.9.2.902] How to set EmulateWheelButton with no hal?
On 12/25/2010 10:31 PM, Peter Hutterer wrote: On Sat, 25 Dec 2010 14:23:08 -0800, waltw41...@gmail.com wrote: Until now I've been using a hal fdi file to set EmulateWheelButton to 8, but now hal is gone, so what to do instead? http://who-t.blogspot.com/2010/01/new-configuration-world-order.html Thanks Peter. I got the emulate wheel working again with this: $cat /etc/X11/xorg.conf.d/10-trackball.conf Section InputClass Identifier pointer MatchProduct ImExPS Driver evdev Option AutoServerLayout on Option Emulate3Buttons on Option EmulateWheel on Option EmulateWheelButton 8 EndSection Even though the mouse works normally, these lines at the end of Xorg.log make me suspect that something is still not right: [ 5223.204] (II) config/udev: Adding input device ImExPS/2 Logitech Explorer Mouse (/dev/input/mouse0) [ 5223.204] (**) ImExPS/2 Logitech Explorer Mouse: Applying InputClass pointer [ 5223.204] (**) ImExPS/2 Logitech Explorer Mouse: always reports core events [ 5223.204] (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/mouse0 [ 5223.204] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [ 5223.204] (II) UnloadModule: evdev [ 5223.204] (EE) PreInit returned NULL for ImExPS/2 Logitech Explorer Mouse Are those errors something to worry about? Thanks! ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[xorg-server-1.9.2.902] How to set EmulateWheelButton with no hal?
Hi xorg list, and Happy Holidays to you all. I just updated xorg-server from 1.7.x to 1.9.2.902. Everything works as expected except for my unusual mouse, which has many buttons but no wheel. Until now I've been using a hal fdi file to set EmulateWheelButton to 8, but now hal is gone, so what to do instead? I have no InputDevice sections in xorg.conf because I've been using evdev and my custom hal fdi file to configure the mouse (successfully). Now I see that xorg is using udev instead of hal to detect the mouse, but somebody is setting EmulateWheelButton to 4. Is this now a default value specified in xorg-server-1.9.x? I'd like to get the Big Picture so I can configure the mouse using the right tool for xorg-1.9.x. Any clues accepted with gratitude and wishes for good holiday cheer :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Evdev keyboard sends keycodes but no keysyms
On 11/14/2010 09:11 AM, Simon Thum wrote: Hi all, yesterday I recompiled xorg, updating from a ca. 3 week old install using gentoo's live ebuilds. I went into an amusing bug which I narrowed down a bit. I'm having the following xorg.conf.d fragment: Section InputClass Identifier keyboard-de MatchIsKeyboard on Option XKBOptions terminate:ctrl_alt_bksp #Option XKBVariant nodeadkeys Option XKBLayout de EndSection Funny enough, invoking setxkbmap -rules evdev -layout de -variant nodeadkeys brings back my keyboard as intended! I notice that your Xorg log says [ 4702.616] (**) Option xkb_rules evdev [ 4702.616] (**) Option xkb_model evdev [ 4702.616] (**) Option xkb_layout us ??? [ 4702.616] (**) Option xkb_variant nodeadkeys [ 4702.616] (**) Option xkb_options terminate:ctrl_alt_bksp Grepping the xorg.conf manpage for InputClass turns up nothing on my xorg-1.7.7 machine. Maybe that's something new? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg will not start
On 10/09/2010 02:48 PM, Edmundo Llopis wrote: I am a newbie to Ubuntu Server 10.04.1 LTS, and I have been struggling for weeks to fix Xorg. Every time I type startx the following appears, can someone provide specific driving instructions to fix this problem. X.Org http://X.Org X Server 1.7.6 (==) Log file: /var/log/Xorg.0.log, Time: Sat Oct 9 17:37:46 2010 (==) Using config directory: /usr/lib/X11/xorg.conf.d Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a3258] What do you have in /usr/lib/X11/xorg.conf.d/ ? Instead of typing 'startx', what happens if you type (as root) 'Xorg -configure' ? Or 'Xorg -help' ? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X freezing occasionally [nouveau bug SOLVED]
On 08/07/2010 05:34 PM, walt wrote: Hi list, Both times X has locked up, firefox was just starting to load a web page that I'd clicked on. (Two different websites.) I can ssh into the machine and use top to see /usr/bin/Xorg using 100% of CPU (an older single-core amd 32-bit cpu) Strace shows Xorg is printing endless numbers of the messages below: ioctl(7, 0x40086482, 0xbffdc7c8) = ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) Kernel is today's Linus.git with its (unmodified) nouveau support. My freezing problem was fixed by this patch: https://bugs.freedesktop.org/attachment.cgi?id=38240 I'm following up here because the patch still hasn't made it to Linus.git as of today, 2010-Sep-06. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
X freezing occasionally
Hi list, This freezing problem happened once yesterday for the first time, and (so far) only once today, so it's not easy to reproduce. I'm running an oddball gemisch of stable and unstable software, so it's definitely not a supported configuration. I'm not at all surprised this is happening, but I thought I'd ask for your observations anyway. Both times X has locked up, firefox was just starting to load a web page that I'd clicked on. (Two different websites.) I can ssh into the machine and use top to see /usr/bin/Xorg using 100% of CPU (an older single-core amd 32-bit cpu). Strace shows Xorg is printing endless numbers of the messages below: ioctl(7, 0x40086482, 0xbffdc7c8)= ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) If I'm interpreting correctly, fd 7 is (no surprise): X 3758 root 7u CHR 226,0 0t02008 /dev/dri/card0 Now for dessert :) (II) NOUVEAU(0): Modeline 1280x1024x76.0 141.82 1280 1376 1512 1744 1024 1025 1028 1070 -hsync +vsync (81.3 kHz) [mi] EQ overflowing. The server is probably stuck in an infinite loop. [Yes, I suspected that already.] Backtrace: 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80a169b] 1: /usr/bin/X (mieqEnqueue+0x196) [0x80a14e6] 2: /usr/bin/X (xf86PostMotionEventP+0xe8) [0x80b4958] 3: /usr/lib/xorg/modules/input/evdev_drv.so (0xb69da000+0x3321) [0xb69dd321] 4: /usr/lib/xorg/modules/input/evdev_drv.so (0xb69da000+0x35c9) [0xb69dd5c9] 5: /usr/bin/X (0x8048000+0x663bf) [0x80ae3bf] 6: /usr/bin/X (0x8048000+0xea23c) [0x813223c] 7: (vdso) (__kernel_sigreturn+0x0) [0xb76f5400] 8: /usr/lib/libdrm.so.2 (drmCommandWrite+0x3b) [0xb715986b] 9: /usr/lib/libdrm_nouveau.so.1 (0xb7176000+0x2e12) [0xb7178e12] 10: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map_range+0xf1) [0xb7179001] 11: /usr/lib/libdrm_nouveau.so.1 (nouveau_bo_map+0x33) [0xb71790d3] 12: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0xb712c000+0x4eca) [0xb7130eca] 13: /usr/lib/xorg/modules/libexa.so (0xb70fa000+0x7602) [0xb7101602] 14: /usr/bin/X (0x8048000+0xaa26d) [0x80f226d] 15: /usr/bin/X (0x8048000+0x43d6e) [0x808bd6e] 16: /usr/bin/X (0x8048000+0x464ff) [0x808e4ff] 17: /usr/bin/X (0x8048000+0x1ddf5) [0x8065df5] 18: /lib/libc.so.6 (__libc_start_main+0xe6) [0xb721bbb6] 19: /usr/bin/X (0x8048000+0x1d9a1) [0x80659a1] Kernel is today's Linus.git with its (unmodified) nouveau support. x11-drivers/xf86-video-nouveau-0.0.16_pre20100615 (gentoo linux) x11-drivers/xf86-input-evdev-2.4.0 x11-libs/libdrm-2.4.21 x11-base/xorg-server-1.7.7-r1 My real question is: how likely is this freezing to be caused by an actual bug somewhere, or is it more likely that my odd mix of package versions just don't play nicely together. BTW, I'm just doing all of this learn something, not to build a production machine. I can afford to tinker with it a bit :) Thanks. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: X freezing occasionally
On 08/07/2010 05:51 PM, Younes Manton wrote: On Sat, Aug 7, 2010 at 8:34 PM, waltw41...@gmail.com wrote: This freezing problem happened once yesterday for the first time, and (so far) only once today, so it's not easy to reproduce. Kernel is today's Linus.git with its (unmodified) nouveau support. x11-drivers/xf86-video-nouveau-0.0.16_pre20100615 (gentoo linux) x11-drivers/xf86-input-evdev-2.4.0 x11-libs/libdrm-2.4.21 x11-base/xorg-server-1.7.7-r1 If you're running an NV50 class card it's likely one of two known bugs in Nouveau and not your software environment. Look for something like the following in your log: [drm] nouveau :01:00.0: Detected an NV50 generation card (0x) Oops, I forgot to mention the hardware, sorry. It's actually older than that. I rescued the video card from the trashcan beside my brother-in-law's gaming machine over a year ago :) nVidia Corporation NV34 [GeForce FX 5200] rev 161 I just thought of a few more experiments I can do to narrow down the diagnosis. Thanks for your quick reply. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Tk installation give Xproto.h Xresource.h missing
On 05/21/2010 01:53 PM, Claudio Cairoli wrote: Hi, I'm trying to install Tcl/tk 8.4.2 on a 64-bit Linux machine, and the installation of tcl went fine, however when trying to install tk at first I got the error message X11/Xlib.h not found. I looked for it in the X11 directory at it wasn't there. I found out that as part of the tk installation there was a directory xlib which contained X11/Xlib.h that fixed that error, but now I am getting Xproto.h and Xresource.h missing. Where are these files supposed to be and how do I get them? They should be in /usr/include/X11/. My linux distribution puts Xresource.h and Xlib.h in the libX11 package, and Xproto.h in a separate package named xproto (contains only header files). Many distributions put header files in separate packages with the suffix dev or devel in the package name, e.g. libX11-dev or something similar. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: multiple monitors configuration without proprietary driver
On 04/09/2010 07:14 AM, Luis Alberto Padrón Hernández wrote: Hello Everybody, I have not been able to get 'nvidia' driver to work, so I need to set my two monitors with 'nv' driver... What is the problem with 'nvidia'? Will it work with a single monitor? ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: nouveau and /dev/dri ? [solved]
On 04/05/2010 03:44 PM, walt wrote: I can't get mesa-7.8 to compile nouveau_dri.so because the gentoo build is ignoring the gallium useflag. ATM glxgears is giving me ~275 FPS, same as the 'nv' driver. Is this because of the missing nouveau_dri.so, maybe? Just for the record, the answer is no. I got nouveau_dri.so compiled by hand and it loads perfectly, no error messages of any kind in the X logs, but glxgears still runs very slowly. It was a fun experiment, but now I have to get back to work :) ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: nouveau and /dev/dri ? [solved]
On 04/05/2010 10:02 AM, walt wrote: Hi, I'm trying nouveau for the first time on amd64 and it's almost but not quite working. The problem is that /dev/dri/ doesn't get created, and I don't know why. I continued to try different kernel config options and got it working, though I'm not sure what made the difference. In retrospect the console framebuffer was not really working before, but it obviously works now. I can't get mesa-7.8 to compile nouveau_dri.so because the gentoo build is ignoring the gallium useflag. ATM glxgears is giving me ~275 FPS, same as the 'nv' driver. Is this because of the missing nouveau_dri.so, maybe? Thanks. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On 11/23/2009 02:04 AM, Dirk Wallenstein wrote:
On Sunday 22 November 2009 23:35:29 walt wrote:
I've mapped my CapsLock key to a plain Shift_L key, using your instructions.
Here is the output of xev (note the keycode is 66):
KeyPress event, serial 30, synthetic NO, window 0x201,
root 0x189, subw 0x0, time 35504647, (136,79), root:(140,822),
state 0x0, keycode 66 (keysym 0xffe1, Shift_L), same_screen YES,
XKeysymToKeycode returns keycode: 50
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
That part is wonderful, but pressing the Caps Lock key doesn't create upper
case letters, but pressing the Shift key does.
Here is the line that I changed in the .xkb file:
keyCAPS { [ Shift_L ] };
What have I missed?
For modifiers, you have to change the modifier_map entry.
Currently, it will look like this:
modifier_map Lock {CAPS };
Change it to:
modifier_map Shift {CAPS };
Yes! The wicked CapsLock witch is dead :o) Thank you.
BTW, I was able to modify the default pc101 easily enough in duttulm to my
desired configuration, but now I have the resulting XML file in ~/.duttulm
and I don't know what to do with it. What comes next?
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [xmodmap] Problem with e and n
On 11/16/2009 08:28 AM, Dirk Wallenstein wrote:
On Sunday 15 November 2009 01:01:49 Maciej Piechotka wrote:
Everything is working except AltGr+e/E and AltGr+n/N. What is wrong?
You probably have to change the key types. You can get the current keymap by
executing this command:
$ xkbcomp -xkb ${DISPLAY} -o keymap.xkb
Now edit the resulting file keymap.xkb and find the sections for the keysym
assignment...
You have to change the values for the type[groupX] entries. Just take the
values from the keys that work, and fill in the keysyms.
You can install the result by executing the following command:
$ xkbcomp keymap.xkb ${DISPLAY}
Hi Dirk, and thanks for the helpful hints.
I've mapped my CapsLock key to a plain Shift_L key, using your instructions.
Here is the output of xev (note the keycode is 66):
KeyPress event, serial 30, synthetic NO, window 0x201,
root 0x189, subw 0x0, time 35504647, (136,79), root:(140,822),
state 0x0, keycode 66 (keysym 0xffe1, Shift_L), same_screen YES,
XKeysymToKeycode returns keycode: 50
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
That part is wonderful, but pressing the Caps Lock key doesn't create upper
case letters, but pressing the Shift key does.
Here is the line that I changed in the .xkb file:
key CAPS { [ Shift_L ] };
What have I missed?
Thanks!
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: libXext 1.1.1
On 10/21/2009 08:36 PM, Alan Coopersmith wrote: -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering Hi Alan, I'm guessing that the email address as it appears above is the reason that some of your digital signatures are rejected by gpg at my end. The posts that are accepted as genuine show your sun.com address instead. I'm puzzled by the randomness of the problem, though. Do you sometimes post through gmane.org and sometimes not? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-cf-files 1.0.3
On 10/14/2009 10:46 AM, Alan Coopersmith wrote: Hi Alan. Just FYI, I'm having trouble with roughly three out of four of your digital signatures, and I have no idea why. Of the three signed posts you made dated 10/14, this is the only one that passes my mail client's gpg sig test. I exported your xclipboard message to disk as an example: $gpg --verify xclipboard\ 1.1.0.eml gpg: Signature made Wed 14 Oct 2009 10:48:55 PM PDT using DSA key ID 1F2D130E gpg: BAD signature from Alan Coopersmith alan.coopersm...@sun.com Is anyone else having this problem? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: pgp signatures
Alan Coopersmith wrote: Robby Workman wrote: Fine for me: $ gpg --verify AlanC-mail gpg: Signature made Wed 14 Oct 2009 12:46:45 PM CDT using DSA key ID 1F2D130E gpg: Good signature from Alan Coopersmith alan.coopersm...@sun.com They seem to come back fine for me too, though the automatic signature appending of the mailing list does cause it to be a bit weird. I use the enigmail plugin for Thunderbird, which calls gpg for the actual signing, to sign the mails. Yes, I do too, but my versions of enigmail (0.96.0) and gpg (2.0.11) are a tiny bit newer than yours. I hope such small changes are not the cause of my problem. I tried a different linux distribution (ubuntu versus gentoo) and I find exactly the same problem on both. ... One of these years we should have a key signing party at the X.Org Developer's Conference. Though I suppose I'll be needing a new key before then when my e-mail address changes... Hm. Are you hinting that you'll be getting an Oracle email address? I'm hoping it's a change in name only, and not in quality. We open source groupies owe a lot to Sun. Not so sure yet about Oracle... ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
On 07/28/2009 09:28 PM, Mikhail Gusarov wrote: Twas brillig at 16:56:51 28.07.2009 UTC-07 when w41...@gmail.com did gyre and gimble: w I'm wondering about the connection from terminal to server, and how w much bandwidth would be typical for such a setting... Have a look at network requirements of LTSP: http://www.ltsp.org/~sbalneav/LTSPManual.html#tc-hardware That's an excellent link, thank you. It answers questions I didn't even know I had :o) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
On 07/28/2009 10:18 AM, Juliusz Chroboczek wrote: Being strictly an amateur programmer, I've always wondered how many people/institutions actually use X for remote display the way it was designed to be used. Quite a lot. In universities in crowded city centers, it is quite common to have students work on (fan-less) X terminals, with a large server pool hidden somewhere in the basement. (Nowadays, the servers are fairly ordinary PCs running Linux, with a few Solaris machines to make the older system administrators happy.)... Very useful info, and thanks to everyone who answered. (I'm afraid to ask how old is 'older'.) (Grad students, maybe?) I'm wondering about the connection from terminal to server, and how much bandwidth would be typical for such a setting. (I'm assuming that college students would spent substantial time watching X-rated videos on their X-terminals ;-) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radical idea for X-modmap problem.
On 07/26/2009 01:56 PM, Jim Gettys wrote: David Moffatt wrote: Responding to the thread about mapping hardware scan codes -- X key codes and keyboards with 248 keys. Perhaps the solution is to take the hardware scan code -- Symbol problem out of the X layer entirely. Let the OS deal with that in its own manner. X already does this: keycodes in X have no need to be even remotely similar to what the operating system does, or what the hardware generates. Keycodes on various other platforms may have values that bear no resemblance to the codes used in Linux, or in IBM derivative keyboards... Being strictly an amateur programmer, I've always wondered how many people/institutions actually use X for remote display the way it was designed to be used. Seems to introduce a great deal of confusing complexity for features many of us never use. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal = Too many input devices.
On 07/06/2009 08:24 PM, Peter Hutterer wrote: On Mon, Jul 06, 2009 at 10:08:50PM +0200, Łukasz Maśko wrote: Dnia poniedziałek, 6 lipca 2009, Peter Hutterer napisał: On Mon, Jul 06, 2009 at 09:26:06AM +0200, Łukasz Maśko wrote: Dnia poniedziałek, 6 lipca 2009, Peter Hutterer napisał: [...] Please attach the whole log, this snippet is not really useful for finding the root of the problem. Here it is. urgh, not as zip file please. Always attach files to bugreports or mailinglists uncompressed - the harder you make it for someone to look at the file the lower the chances that someone does. Sorry, but the log file after 14 days has200KB, therefore I didn't attach it to my mail uncompressed. if the file is really as long as you claim, check for add/remove devices. There is nothing suspicious in the part before the logs, that I've written about yesterday. Besides, everything had worked till then. I remember a bluetooth bug where devices never get removed, so each time the mouse connected it would be added as new device - with the old one still staying there. Everytime I hibernate, I stop the bluetooth susbsystem and unload USB modules - required by tuxonice. So it would have been be strange, if the counter was increased and not reseted while subsystem restart. If I come accross this problem again I'll check, if the mouse stops working under console. try exactly that then - restarting bluetooth or usb over and over again. the server-internal counter is at 20 (40 in git) so it's easy enough to trigger. if you're running a git server, just run xinput --create-master foo a few times to increase the number of devices already present. this way the the error will happen sooner. Just wondering if lshal would also reflect the increasing number of mice? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev+hal = Too many input devices.
On 07/05/2009 01:41 PM, Łukasz Maśko wrote: I have a Kingston BT mouse, which works pretty well with my Linux laptop. At least it has worked so far, becouse this is what I'm getting in log files right now, when I turn it on: (II) config/hal: Adding input device Primax Corp. (3) Button Mouse (**) Primax Corp. (3) Button Mouse: always reports core events (**) Primax Corp. (3) Button Mouse: Device: /dev/input/event10 (II) Primax Corp. (3) Button Mouse: Found 3 mouse buttons (II) Primax Corp. (3) Button Mouse: Found x and y relative axes (II) Primax Corp. (3) Button Mouse: Found scroll wheel(s) (II) Primax Corp. (3) Button Mouse: Found keys (II) Primax Corp. (3) Button Mouse: Configuring as mouse (II) Primax Corp. (3) Button Mouse: Configuring as keyboard (**) Primax Corp. (3) Button Mouse: YAxisMapping: buttons 4 and 5 (**) Primax Corp. (3) Button Mouse: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (EE) Too many input devices. Ignoring Primax Corp. (3) Button Mouse (II) UnloadModule: evdev Do you have the mouse driver in your xorg.conf? Identifier Mouse1 Driver mouse === This is not needed if you use evdev. (Same for the keyboard driver.) Try commenting out the entire Input section if you have one. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Matt Hayes wrote: Dan Nicholson wrote: On Fri, Jun 12, 2009 at 5:46 AM, Matt Hayesdomin...@slackadelic.com wrote: Hrm.. so where the heck is the 32 buttons coming from? That's very odd and causes mapping of buttons to be a pita. The evdev driver. Perhaps you were using the mouse driver in xorg.conf? That is possible. I will have to look at changing the mouse driver in a hal policy or Xorg.conf and see what that reveals. I recently switched to using evdev and when I removed the InputDevice sections from xorg.conf I had to add an fdi file to /etc/hal/fdi/policy (which I cleverly named 10-x11-logitech.fdi) containing this: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.product contains=ImExPS/2 merge key=input.x11_options.EmulateWheel type=stringtrue/merge merge key=input.x11_options.EmulateWheelButton type=string8/merge /match /device /deviceinfo I constructed that file by looking at mouse-oriented parts of the output of 'lshal' and just stuck the options in where it looked reasonable. It worked, and I'm still amazed. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Strange issue with hal and Xorg
Justin Mattock wrote: Don't want to confuse you, but hal is being fazed out. udev-142 is now responsible for handling volumeid etc... Auuuggh! Just when I'm beginning to understand hal (but not very well.) You've confused me too. How does volumeid relate to a mouse problem? And which docs should I start reading before this actually happens? And have a nice weekend :o) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Help interpreting evdev error messages?
Peter Hutterer wrote: On Tue, Apr 07, 2009 at 06:52:42PM -0700, walt wrote: My linux distribution (gentoo) just updated to xorg-server 1.5.3 and evdev 2.1.3. I have it almost-but-not-quite working...the mouse works except for emulate-wheel, which was working before the update. ... Section InputDevice Identifier Mouse0 Option Device /dev/input/mice /dev/input/mice is not an evdev device... Thanks, that was what I needed. Happily, when I use the correct device the correct emulate-wheel button is read from xorg.conf. I still see errors from X, though. Are these normal? (**) Option CorePointer (**) Mouse0: always reports core events (**) Mouse0: Device: /dev/input/event4 (II) Mouse0: Found 5 mouse buttons (II) Mouse0: Found x and y relative axes (II) Mouse0: Configuring as mouse (**) Option Emulate3Buttons True (II) Mouse0: Forcing middle mouse button emulation on. (**) Option EmulateWheel True (**) Option EmulateWheelButton 8 (**) Mouse0: YAxisMapping: buttons 4 and 5 (**) Mouse0: EmulateWheelButton: 8, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (**) Option CoreKeyboard (**) Keyboard0: always reports core events (**) Keyboard0: Device: /dev/input/event3 (II) Keyboard0: Found keys (II) Keyboard0: Configuring as keyboard (II) evaluating device (Mouse0) (II) XINPUT: Adding extended input device Mouse0 (type: MOUSE) (II) evaluating device (Keyboard0) (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us From 10-keymap.fdi? *** (II) config/hal: Adding input device ImExPS/2 Logitech Explorer Mouse (**) ImExPS/2 Logitech Explorer Mouse: always reports core events (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/event4 (WW) ImExPS/2 Logitech Explorer Mouse: device file already in use. Ignoring. (II) UnloadModule: evdev ** Is this normal? *** (EE) PreInit returned NULL for ImExPS/2 Logitech Explorer Mouse (EE) config/hal: NewInputDeviceRequest failed In spite of these errors the mouse is working perfectly now. The man page for evdev says nothing about the keyboard, oddly. My keyboard is not a standard pc105 so some of my keys are cross- wired, e.g. the up-arrow key sends a PrtScn/SysRq instead. Do I need to customize 10-keymap.fdi? (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event3 (WW) AT Translated Set 2 keyboard: device file already in use. Ignoring. (II) UnloadModule: evdev (EE) PreInit returned NULL for AT Translated Set 2 keyboard (EE) config/hal: NewInputDeviceRequest failed Thanks for your help! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Help interpreting evdev error messages?
walt wrote: My keyboard is not a standard pc105 so some of my keys are cross- wired, e.g. the up-arrow key sends a PrtScn/SysRq instead... Please ignore that part. I rebooted the machine and the problem vanished. So now both the keyboard and mouse are working perfectly. I'd still like to know about the remaining error messages in my previous post, though, so if you have any ideas I'd be grateful. Should I just ignore them? Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Help interpreting evdev error messages?
My linux distribution (gentoo) just updated to xorg-server 1.5.3 and evdev 2.1.3. I have it almost-but-not-quite working. The keyboard works correctly AFAICT and the mouse works except for emulate-wheel, which was working before the update. I see these errors from the X server: (**) Option CorePointer (**) Mouse0: always reports core events (**) Mouse0: Device: /dev/input/mice (EE) ioctl EVIOCGBIT failed: Inappropriate ioctl for device (II) UnloadModule: evdev (EE) PreInit returned NULL for Mouse0 (**) Option CoreKeyboard (**) Keyboard0: always reports core events (EE) Keyboard0: No device specified. (II) UnloadModule: evdev (EE) PreInit returned NULL for Keyboard0 (II) config/hal: Adding input device ImExPS/2 Logitech Explorer Mouse (**) ImExPS/2 Logitech Explorer Mouse: always reports core events (**) ImExPS/2 Logitech Explorer Mouse: Device: /dev/input/event4 (II) ImExPS/2 Logitech Explorer Mouse: Found 5 mouse buttons **WRONG** (II) ImExPS/2 Logitech Explorer Mouse: Found x and y relative axes (II) ImExPS/2 Logitech Explorer Mouse: Configuring as mouse (**) ImExPS/2 Logitech Explorer Mouse: YAxisMapping: buttons 4 and 5 (**) ImExPS/2 Logitech Explorer Mouse: EmulateWheelButton: 4,**WRONG** EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device ImExPS/2 Logitech Explorer Mouse (type: MOUSE) (II) config/hal: Adding input device AT Translated Set 2 keyboard (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: /dev/input/event3 (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us I have this in xorg.conf: Section InputDevice Identifier Keyboard0 Driver evdev EndSection Section InputDevice Identifier Mouse0 Driver evdev Option Protocol auto Option Device /dev/input/mice Option Emulate3Buttons True Option EmulateWheel True Option EmulateWheelButton 8 ---NOTE EndSection As you can see, EmulateWheel is broken because the button has the wrong value, I'm guessing because the evdev module was un- loaded for some reason. I have CONFIG_INPUT_EVDEV=y in my kernel config. Any idea where I'm going wrong? Thanks! ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
