Bug 15839 - Xephyr gets BadDrawable on x86_64 because hostx.c is built with _XSERVER64
Summary: Xephyr gets BadDrawable on x86_64 because hostx.c is built with _XSERVER64
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xephyr (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Dodji Seketeli
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: xorg-7.4
  Show dependency treegraph
 
Reported: 2008-05-05 16:42 UTC by Aaron Plattner
Modified: 2008-08-29 13:34 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Plattner 2008-05-05 16:42:54 UTC
Xephyr fails to run on a Linux x86_64 system because hostx.c is built with _XSERVER64 defined.  It dies with this error:

X Error of failed request:  BadDrawable (invalid Pixmap or Window parameter)
  Major opcode of failed request:  55 (X_CreateGC)
  Resource id in failed request:  0x0
  Serial number of failed request:  7
  Current serial number in output stream:  12

This happens because RootWindow(HostX.dpy, HostX.screen) is returning None.

This broke with this commit:

commit 6a435b00003fb00930299a0e0810c93afc23a72e
Author: Dodji Seketeli <dodji@openedhand.com>
Date:   Wed Sep 19 15:35:51 2007 +0200

    Xephyr: check presence of extensions in host X
    
        * hw/kdrive/ephyr/hostx.c,h:
          (hostx_has_xshape),
          (hostx_has_glx),
          (hostx_has_dri): added these new entry points
        * hw/kdrive/ephyr/ephyrdriext.c:
          (ephyrDRIExtensionInit):
          check presence of DRI and XShape extensions before
          trying to use them.
        * hw/kdrive/ephyr/ephyrglxext.c:
          (ephyrHijackGLXExtension):
          check presence of glx extension before we use it.

which causes that file to include kdrive-config.h, which in turn includes dix-config.h, which defines _XSERVER64.
Comment 1 Martin Dengler 2008-06-09 22:08:32 UTC
I seem to have come across this in Fedora 9.
Comment 2 Dodji Seketeli 2008-06-20 07:35:29 UTC
Okay, if you don't mind, I will look at this.
Comment 3 Martin Dengler 2008-06-29 07:33:12 UTC
Thanks for looking at this!
Comment 4 Pascal Scheffers 2008-07-15 04:49:53 UTC
I'd love to see this fixed. It prevents me from running a working OLPC emulator on my Fedora 9 laptop 
Comment 5 Julien Cristau 2008-07-22 12:54:44 UTC
Dodji, any progress on fixing this, or should we just revert the bad commit for 1.5?
Comment 6 Dodji Seketeli 2008-07-22 13:21:44 UTC
I have just got myself an x86_64 box to test this. Before that I didn't have such an environment.

I will be able to test the problem and hopefully come to a solution.

I am very sorry for the delay.
Comment 7 Dodji Seketeli 2008-07-22 16:13:32 UTC
So have committed http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=5de1867fbb0a336ff3fdc92cbf734849f6111b1b that seems to fix it for me.

I have also committed a patch to fix various build issues on X86_64.

I hope it works for you.
Comment 8 Hubert Figuiere 2008-07-22 16:54:42 UTC
I applied the patches and now it works here on x86_64

Thanks a lot.
Comment 9 Martin Dengler 2008-08-29 13:34:23 UTC
Just wanted to say thanks - I've been using the rpms at http://koji.fedoraproject.org/koji/buildinfo?buildID=57371 with this patch and it's great.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.