Xorg, libpciaccess and /dev/mem

[Jérémie Koenig]

Hello,

I have been trying to make Xorg work with my MGA G450 card. One
problem I stumbled upon was the MGA driver trying to map the video
memory through libpciaccess, which failed with ENXIO (no such device
or address).

Upon inspection it turns out that the libpciaccess x86_pci.c generic
code uses mmap() on /dev/mem. While MAKEDEV does create a /dev/mem
device with '/hurd/storeio --no-cache mem' as its translator, it seems
GNU Mach does not have such a device (antrik suggested on #hurd
yesterday that oskit-mach might).

On the other hand, using '/hurd/storeio --no-cache iopl' for /dev/mem
seems to fix the problem (my X server crashes a little later). I
beleive using the iopl device directly as is done for the Xorg server
(hw/xfree86/os-support/hurd/hurd_video.c) in libpciaccess could work
as well, though my attempt at this apparently did not completely work
(one line was missing in the Xorg.log compared to the "/dev/mem =
iopl" solution, and my Linux X server logs, regarding detection of the
video bios).

I'd be glad to create a bug report and/or submit a patch, but I'm a
little lost about what should do what:
  * should MAKEDEV create /dev/mem using the iopl device instead of
the non-existing 'mem' ? (and does this really work?)
  * should it not create it at all?
  * should libpciaccess have some Mach-specific code similar to the Xorg code?

By the way, some other problems I have (I will investigate those further):
  * Using the VESA driver, the X server crashes with SIGILL. The
backtrace shown suggests this happens in the int10 code.
  * I'm able to use gdb on the X server through the network but when I
try to rebuild the xorg-server source package with
DEB_BUILD_OPTIONS=debug,nostrip, I get a segfault from libtool. (Could
someone confirm they have this problem as well?)

Thanks for any advice/suggestion you might have,

-- 
Jérémie Koenig <jk@jk.fr.eu.org>
http://jk.fr.eu.org/