Fedora 10, Belkin KVM, USB Mouse/Keyboard, NVIDIA Card, OpenOffice
Hello, Here is the setup. I am running two different desktop computers, each with their own monitor, but with only one keyboard / mouse. I am using a Belkin KVM switch to control the keyboard / mouse function between the two. The switch has USB inputs and USB outputs. I am running Fedora10 (F1)0) on each desktop computer. Each has a different NVIDIA Quadro card installed, and I am running NVIDIA drivers (different version of each because the one card is not supported anymore). Everything works fine, until I launch OpenOffice on either computer. At that point, when I use the KVM to switch mouse / keyboard to the other desktop X will crash. I have not been able to reproduce this with anything other than the OpenOffice suite of applications. It has something to do with the evdev module here is the backtrace in the Xorg.0.log (EE) Belkin Corporation Flip CC: Read error: No such device (II) config/hal: removing device Belkin Corporation Flip CC (II) Belkin Corporation Flip CC: Close (II) UnloadModule: evdev (EE) Dell Dell USB Keyboard: Read error: No such device (II) config/hal: removing device Dell Dell USB Keyboard (II) Dell Dell USB Keyboard: Close (II) UnloadModule: evdev (II) config/hal: Adding input device Belkin Corporation Flip KVM (**) Belkin Corporation Flip KVM: always reports core events (**) Belkin Corporation Flip KVM: Device: /dev/input/event3 (II) Belkin Corporation Flip KVM: Found 5 mouse buttons (II) Belkin Corporation Flip KVM: Found x and y relative axes (II) Belkin Corporation Flip KVM: Configuring as mouse (**) Belkin Corporation Flip KVM: YAxisMapping: buttons 4 and 5 (**) Belkin Corporation Flip KVM: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device Belkin Corporation Flip KVM (type: MOUSE) (II) config/hal: Adding input device Belkin Corporation Flip KVM (**) Belkin Corporation Flip KVM: always reports core events (**) Belkin Corporation Flip KVM: Device: /dev/input/event7 (II) Belkin Corporation Flip KVM: Found keys (II) Belkin Corporation Flip KVM: Configuring as keyboard (II) XINPUT: Adding extended input device Belkin Corporation Flip KVM (type: KEYBOARD) (**) Option xkb_rules evdev (**) Belkin Corporation Flip KVM: xkb_rules: evdev (**) Option xkb_model pc105+inet (**) Belkin Corporation Flip KVM: xkb_model: pc105+inet (**) Option xkb_layout us (**) Belkin Corporation Flip KVM: xkb_layout: us Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7a26] 1: /usr/bin/Xorg(xf86SigHandler+0x39) [0x47a679] 2: /lib64/libc.so.6 [0x33dac32f90] 3: /usr/bin/Xorg(XkbStringText+0x1c) [0x56711c] 4: /usr/bin/Xorg(XkbWriteXKBGeometry+0x191) [0x5587d1] 5: /usr/bin/Xorg(XkbWriteXKBKeymapForNames+0x5bb) [0x557d1b] 6: /usr/bin/Xorg(XkbDDXLoadKeymapByNames+0x18a) [0x561cba] 7: /usr/bin/Xorg(ProcXkbGetKbdByName+0x3ab) [0x53fb2b] 8: /usr/bin/Xorg(Dispatch+0x364) [0x4468d4] 9: /usr/bin/Xorg(main+0x45d) [0x42cd1d] 10: /lib64/libc.so.6(__libc_start_main+0xe6) [0x33dac1e576] 11: /usr/bin/Xorg [0x42c0f9] Fatal server error: Caught signal 11. Server aborting (II) Power Button (FF): Close (II) UnloadModule: evdev (II) Power Button (CM): Close (II) UnloadModule: evdev (II) Macintosh mouse button emulation: Close (II) UnloadModule: evdev (II) USB Optical Mouse: Close (II) UnloadModule: evdev (II) Belkin Corporation Flip KVM: Close (II) UnloadModule: evdev (II) Belkin Corporation Flip KVM: Close (II) UnloadModule: evdev Also, here is my xorg.conf [r...@cio11-6305z usr]# cat /etc/X11/xorg.conf # nvidia-xconfig: X configuration file generated by nvidia-xconfig # nvidia-xconfig: version 1.0 (buildmeis...@builder58) Thu Jul 17 18:39:00 PDT 2008 # Xorg configuration created by system-config-display Section ServerLayout Identifier single head configuration Screen 0 Screen0 0 0 #InputDeviceMouse0 CorePointer #InputDeviceKeyboard0 CoreKeyboard EndSection #Section InputDevice # generated from default #Identifier Mouse0 #Driver mouse #Option Protocol auto #Option Protocol ImPS/2 #Option Device /dev/input/mice #Option Emulate3Buttons no #Option ZAxisMapping 4 5 #EndSection #Section InputDevice # keyboard added by rhpxl #Identifier Keyboard0 #Driver kbd #Option XkbModel pc105 #Option XkbLayout us #EndSection Section Monitor Identifier Monitor0 VendorName Unknown ModelName Unknown HorizSync 30.0 - 110.0 VertRefresh 50.0 - 150.0 Option DPMS EndSection Section Device Identifier Videocard0 Driver nvidia EndSection Section Screen Identifier Screen0 Device Videocard0 MonitorMonitor0 DefaultDepth24 Option TwinView True Option MetaModes nvidia-auto-select, nvidia-auto-select SubSection Display Viewport0 0 Depth 24
Re: [PATCH] glx: Replace broken GLX visual setup with a fixed all mode.
On Sun, Feb 8, 2009 at 7:00 AM, Eric Anholt e...@anholt.net wrote: With trying to match depths so that you didn't end up with a depth 24 fbconfig for the 32-bit composite visual, I broke the alpha bits on the depth 24 X visual, which angered other applications. But in fixing that, the pickFBconfigs code for minimal also could end up breaking GLX visuals if the same FBconfig was chosen for more than one X visual. We have no reason to not expose as many visuals as possible, but the old all mode didn't match any existing X visuals to GLX visuals, so normal GL apps didn't work at all. Instead, replace it with a simple combination of the two modes: Create GLX visuals by picking unique FBconfigs with as many features as possible for each X visual in order. Then, for all remaining FBconfigs that are appropriate for display, add a corresponding X and GLX visual. This gets all applications (even ones that aren't smart enough to do FBconfigs) get all the options to get the visual configuration they want. The only potential downside is that the composite ARGB visual is unique and gets a nearly full-featured GLX visual (except that the root visual might have taken the tastiest FBconfig), which means that a dumb compositing manager could waste resources. Write compositing managers using FBconfigs instead, please. That's probably fine. The code in question was, erhm a little un-inspired and I never liked the option. Looks good to me. cheers, Kristian ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
On Thursday 05 February 2009, Maarten Maathuis wrote: --- exa/exa_accel.c |4 +- fb/fb.h | 37 -- fb/fbcopy.c | 331 +-- fb/fboverlay.c | 2 +- fb/fboverlay.h |2 +- fb/fbwindow.c |2 +- mi/Makefile.am |1 + mi/mi.h | 42 +++ mi/micopy.c | 354 +++ 9 files changed, 406 insertions(+), 369 deletions(-) create mode 100644 mi/micopy.c Removing fbDoCopy and fbCopyRegion from xserver (git commit 2e76958d304a3c4080d62f32449724eeb9b95d93) breaks uxa acceleration in the intel driver. The server crashes as soon as uxa_copy_area or uxa_copy_window are called. At least the equivalent of the exa_accel patch needs to be applied to the intel driver to restore working uxa acceleration with git HEAD of xserver. However, since the intel driver presumably is supposed to work with older versions, too, some version checking might be required as well. A simplistic patch just calling the new mi copy functions is attached. diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c index f42e0e2..7053067 100644 --- a/uxa/uxa-accel.c +++ b/uxa/uxa-accel.c @@ -492,7 +492,7 @@ uxa_copy_area(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, srcx, srcy, width, height, dstx, dsty); } -return fbDoCopy (pSrcDrawable, pDstDrawable, pGC, +return miDoCopy (pSrcDrawable, pDstDrawable, pGC, srcx, srcy, width, height, dstx, dsty, uxa_copy_n_to_n, 0, NULL); } @@ -840,7 +840,7 @@ uxa_copy_window(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc) -pPixmap-screen_x, -pPixmap-screen_y); #endif -fbCopyRegion (pPixmap-drawable, pPixmap-drawable, +miCopyRegion (pPixmap-drawable, pPixmap-drawable, NULL, rgnDst, dx, dy, uxa_copy_n_to_n, 0, NULL); Regards, Magnus Kessler ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
I'll wait a bit to see what the preferred solution is, but i see three options atm. - A wrapper function in fbcopy.c - A define in fb.h, silently converting fbFoo into miFoo - User side fixes Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, Belkin KVM, USB Mouse/Keyboard, NVIDIA Card, OpenOffice
On Tue, Feb 10, 2009 at 10:04 AM, Kevin Johnson kpj...@gmail.com wrote: Hello, Here is the setup. I am running two different desktop computers, each with their own monitor, but with only one keyboard / mouse. I am using a Belkin KVM switch to control the keyboard / mouse function between the two. The switch has USB inputs and USB outputs. I am running Fedora10 (F1)0) on each desktop computer. Each has a different NVIDIA Quadro card installed, and I am running NVIDIA drivers (different version of each because the one card is not supported anymore). Everything works fine, until I launch OpenOffice on either computer. At that point, when I use the KVM to switch mouse / keyboard to the other desktop X will crash. I have not been able to reproduce this with anything other than the OpenOffice suite of applications. It has something to do with the evdev module here is the backtrace in the Xorg.0.log (EE) Belkin Corporation Flip CC: Read error: No such device (II) config/hal: removing device Belkin Corporation Flip CC (II) Belkin Corporation Flip CC: Close (II) UnloadModule: evdev (EE) Dell Dell USB Keyboard: Read error: No such device (II) config/hal: removing device Dell Dell USB Keyboard (II) Dell Dell USB Keyboard: Close (II) UnloadModule: evdev (II) config/hal: Adding input device Belkin Corporation Flip KVM (**) Belkin Corporation Flip KVM: always reports core events (**) Belkin Corporation Flip KVM: Device: /dev/input/event3 (II) Belkin Corporation Flip KVM: Found 5 mouse buttons (II) Belkin Corporation Flip KVM: Found x and y relative axes (II) Belkin Corporation Flip KVM: Configuring as mouse (**) Belkin Corporation Flip KVM: YAxisMapping: buttons 4 and 5 (**) Belkin Corporation Flip KVM: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 (II) XINPUT: Adding extended input device Belkin Corporation Flip KVM (type: MOUSE) (II) config/hal: Adding input device Belkin Corporation Flip KVM (**) Belkin Corporation Flip KVM: always reports core events (**) Belkin Corporation Flip KVM: Device: /dev/input/event7 (II) Belkin Corporation Flip KVM: Found keys (II) Belkin Corporation Flip KVM: Configuring as keyboard (II) XINPUT: Adding extended input device Belkin Corporation Flip KVM (type: KEYBOARD) (**) Option xkb_rules evdev (**) Belkin Corporation Flip KVM: xkb_rules: evdev (**) Option xkb_model pc105+inet (**) Belkin Corporation Flip KVM: xkb_model: pc105+inet (**) Option xkb_layout us (**) Belkin Corporation Flip KVM: xkb_layout: us Backtrace: 0: /usr/bin/Xorg(xorg_backtrace+0x26) [0x4e7a26] 1: /usr/bin/Xorg(xf86SigHandler+0x39) [0x47a679] 2: /lib64/libc.so.6 [0x33dac32f90] 3: /usr/bin/Xorg(XkbStringText+0x1c) [0x56711c] 4: /usr/bin/Xorg(XkbWriteXKBGeometry+0x191) [0x5587d1] 5: /usr/bin/Xorg(XkbWriteXKBKeymapForNames+0x5bb) [0x557d1b] 6: /usr/bin/Xorg(XkbDDXLoadKeymapByNames+0x18a) [0x561cba] 7: /usr/bin/Xorg(ProcXkbGetKbdByName+0x3ab) [0x53fb2b] 8: /usr/bin/Xorg(Dispatch+0x364) [0x4468d4] 9: /usr/bin/Xorg(main+0x45d) [0x42cd1d] 10: /lib64/libc.so.6(__libc_start_main+0xe6) [0x33dac1e576] 11: /usr/bin/Xorg [0x42c0f9] Might be helpful to get a full backtrace. Start up the server as normal, attach gdb to the Xorg pid, then trigger the crash and type bt in gdb. I would guess there's bad things going on in XKB, but XkbStringText shouldn't be crashing. -- Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fedora 10, Belkin KVM, USB Mouse/Keyboard, NVIDIA Card, OpenOffice
On Tue, Feb 10, 2009 at 01:04:06PM -0500, Kevin Johnson wrote: Here is the setup. I am running two different desktop computers, each with their own monitor, but with only one keyboard / mouse. I am using a Belkin KVM switch to control the keyboard / mouse function between the two. The switch has USB inputs and USB outputs. I am running Fedora10 (F1)0) on each desktop computer. Each has a different NVIDIA Quadro card installed, and I am running NVIDIA drivers (different version of each because the one card is not supported anymore). Everything works fine, until I launch OpenOffice on either computer. At that point, when I use the KVM to switch mouse / keyboard to the other desktop X will crash. I have not been able to reproduce this with anything other than the OpenOffice suite of applications. It has something to do with the evdev module here is the backtrace in the Xorg.0.log The matching bug in the Red Hat bugzilla is https://bugzilla.redhat.com/show_bug.cgi?id=469572 It's caused by (I think) a dangling pointer in the xkb geometry code, but I have not been able to reproduce and/or track it down yet. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] XI2 draft protocol specification (v 0.1)
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).
Please see the diff below your comments. Is that clearer now?
On Mon, Feb 09, 2009 at 03:57:48PM +0100, Simon Thum wrote:
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
num_changes: CARD8
changes: LISTofHIERARCHYCHANGES
└───
HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, CHANGEATTACHMENT }
HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, ChangeAttachment }
CHANGEMODE { Float, Attach }
I'd split HIERARCHYCHANGE into four: CM, RM, DetachSlave, AttachSlave -
thereby getting rid of CHANGEMODE.
The server processes the changes one by one and applies changes
immediately. If an error occurs, processing stops at the current change
and the error is returned to the client.
The point it stopped might be interesting to the client (only if it's
easy to report)
┌───
XISetClientPointer
win: Window
▶
set: BOOL
deviceid:DEVICEID
└───
Query the ClientPointer for the client owning 'win'.
I guess XI*G*etClientPointer is meant.
┌───
RawEvent
EVENTHEADER
eventtype: RAWTYPE
detail:CARD32
buttons_len: CARD16
valuators_len: CARD16
buttons: SETofBUTTONMASK
valuators: SETofVALUATORMASK
valuators_unaccel: SETofVALUATORMASK
axisvalues:LISTofFP3232
axisvalues_unaccel:LISTofFP3232
└───
RAWTYPE { Motion, KeyPress, KeyRelease, ButtonPress, ButtonRelease }
A RawDevice event provides the information provided by the driver to the
client. RawDevice events are only generated for slave devices.
Unaccelerated and accelerated valuator data is provided if applicable.
Of course acceleration is, right now, the only thing that could happen
to valuators after the driver is finished, but I'd avoid a direct
reference to it in the spec. (un-)transformed or adjusted seems a better
choice to me. Or 'raw'.
valuators
Bitmask of valuators provided in 'axisvalues'.
valuators_unaccel
Bitmask of valuators provided in 'axisvalues_unaccel'.
It might make sense to say something about their correlation, i.e. will
both be reported when available? The description: 'Unaccelerated and
accelerated valuator data is provided if applicable.' may mean: 'If an
axis is accelerated/translated, the server may/must omit the
untranslated value'.
IOW, what exactly is 'applicable'?
diff --git a/XI2proto.txt b/XI2proto.txt
index 6bbb89d..cd64b61 100644
--- a/XI2proto.txt
+++ b/XI2proto.txt
@@ -130,8 +130,9 @@ EVENTMASK
A SETofEVENTMASK is a binary OR of zero or more EVENTMASK.
FP1616
-Fixed point decimal in 16.16 format as 32 bit integer. The client is
-required to convert to 16.16 decimal format.
+Fixed point decimal in 16.16 format as 32 bit integer in the form of
+(value * 10e15). The client is required to convert to 16.16 decimal
+format.
FP3232
Fixed point decimal in 32.32 format as one INT32 and one CARD32.
@@ -450,9 +451,10 @@ XI2. Clients should ignore this data.
changes: LISTofHIERARCHYCHANGES
└───
-HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, CHANGEATTACHMENT }
+HIERARCHYCHANGE { CREATEMASTER, REMOVEMASTER, ATTACHSLAVE, DETACHSLAVE }
-HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, ChangeAttachment }
+HIERARCHYCHANGETYPE { CreateMaster, RemoveMaster, SlaveAttached,
+ SlaveDetached }
CHANGEMODE { Float, Attach }
@@ -470,11 +472,14 @@ XI2. Clients should ignore this data.
return_pointer: DEVICEID
return_keyboard: DEVICEID }
-CHANGEATTACHMENT { type:HIERARCHYCHANGETYPE
- length: CARD16
- deviceid:DEVICEID
- change_mode: CHANGEMODE
- master: DEVICEID }
+ATTACHSLAVE { type:HIERARCHYCHANGETYPE
+length: CARD16
+deviceid:DEVICEID
+master: DEVICEID }
+
+DETACHSLAVE { type: HIERARCHYCHANGETYPE
+ length: CARD16
+ deviceid: DEVICEID }
XIChangeDeviceHierarchy allows a client
Re: [PATCH 8/9] fb: move some code to mi
On Wed, 2009-02-11 at 00:06 +0100, Maarten Maathuis wrote: I'll wait a bit to see what the preferred solution is, but i see three options atm. - A wrapper function in fbcopy.c - A define in fb.h, silently converting fbFoo into miFoo - User side fixes The first one would be the only ABI preserving solution. The wrappers could be removed next time we need to break ABI for other reasons. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
