Bug 224311

Summary: Xephyr segfaults on startup
Product: [Fedora] Fedora Reporter: Jonathan Eskritt <jeskritt>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-01-29 23:02:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Jonathan Eskritt 2007-01-25 07:16:03 UTC
Description of problem:
I try to start a Xephyr window using:
Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac
as described in the  maemo 3.0 tutorial
(http://maemo.org/platform/docs/howtos/Maemo_tutorial_bora.html)

but it segfaulst with the error:
Extended Input Devices not yet supported. Impelement it at line 625 in kinput.c
Segmentation fault

Version-Release number of selected component (if applicable):
xorg-x11-server-Xephyr-1.1.1-47.4.fc6

How reproducible:
everytime

Steps to Reproduce:
1. Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac

Actual results:
A window frame beirfly appears before a segfault occurs

Expected results:
a xephyr window should appear

Additional info:

Comment 1 Adam Jackson 2007-01-29 23:02:07 UTC
This appears to be a 64-bitness bug in Xephyr.  hostx.c is being built all
wrong; KeySym is defined as XID is defined as unsigned long, which would be fine
on 32 bit but not here.  As a result, the keymap fill code walks off into other
bits of .data, and smashes the cursor private index, so the next call to
pScreen->RealizeCursor() explodes.  Pretty cool!

hostx.c is special and needs to thunk between X server and Xlib types, which are
not the same sizes even though they're the same type names.  So basically you
can't ever talk about KeySyms, you just have to know that they're unsigned
32-bit ints.  So gross.  But, fixed in 1.2.0-3 and in 1.1.1-47.5.fc6, the latter
of which will be in updates shortly.

Thanks!