Modular X server bugs, annoyances and solutions (Part 1)

[Voltago]

Anyone who wants to give X11R7 a spin should first read this migration guide by spyderous:
http://dev.gentoo.org/~spyderous/xorg-x ... _howto.txt
Now that a meta ebuild for necessary xorg components is available, don't emerge xorg-server directly, rather do

Code: Select all

emerge =xorg-x11-7.0.0_rc1

A few additional considerations:

1. You should know what you are doing (to a certain degree).
2. If you want to use the synaptics driver, you can download this ebuild I had to adjust slightly:
   http://demandiseineseite.gmxhome.de/syn ... 4.3.ebuild
3. If you use evdev drivers for your pointer devices, you may find that button two and three are swapped. On my laptop, this doesn't happen for any device if I use my touchpad with the synaptics driver.
4. Somehow I found xfree86-dga (you need it e. g. for vmware-workstation-4.5 fullscreen mode; vmware 5.5beta doesn't have this problem)
5. The kdm compilation failure due to missing imake has been sorted out as of kdm-3.4.3-r1

2005-12-28 sticky --Earthwings

[thubble]

A problem a few of us have been having is that gnome-settings-daemon fails to start under modular xorg. I get this error on startup:

Code: Select all

You can only run one xsettings manager at a time; exiting

Only other problem I've had is that none of the required x11-libs/libX* libraries are merged, due to no dependencies. I just emerged the ones they were complaining about manually, and everything works now.

[Voltago]

Update: The new libX11 snapshot solved my kaffeine problem (my kaffeine-the-video-player-problem, not the other one). W00t! I'll celebrate this with a double espresso...

[n0n]

I've just given the modular X a try today, and I've been unable to get it to last long enough to get a window manager. It seems to be doing okay while it first boots up, then I get maybe half a second of the mouse cursor, and then the server shuts down, seemingly without any related error. I'm using the i810 driver, if that helps at all.

There are a few things suspicious in the logfile...

For instance, there's this:

Code: Select all

(II) I810(0): [drm] removed 1 reserved context for kernel
(II) I810(0): [drm] unmapping 8192 bytes of SAREA 0xe00e2000 at 0x407e2000
(WW) I810(0): Successfully set original devices
(WW) I810(0): Setting the original video mode instead of restoring
        the saved state
(WW) I810(0): Extended BIOS function 0x5f05 failed.
(II) I810(0): BIOS call 0x5f05 not supported, setting refresh with VBE 3 method.
(II) I810(0): xf86UnbindGARTMemory: unbind key 7

towards the end, though that just looks like it's falling back to some default behavior or something. There's also this:

Code: Select all

FreeFontPath: FPE "/usr/share/fonts/misc/" refcount is 2, should be 1; fixing.

which is always the last line in the file, but that doesn't seem like the kind of thing that would bring down the whole server.

I can't load type1 or xtrap; could that be the problem? Does the server actually require either of those to stay up? Right now I've just been trying it with those lines commented in x.org, but that doesn't seem to affect the actual problem.

The only other odd thing in the logfile is this:

Code: Select all

(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/lib/xorg/modules/libint10.so
(II) I810(0): initializing int10
(WW) I810(0): Bad V_BIOS checksum

which occurs a few times. Don't know if that's significant either.

This is using xorg-server-0.99.1-r8, btw.

[n0n]

I can't load type1 or xtrap; could that be the problem? Does the server actually require either of those to stay up? Right now I've just been trying it with those lines commented in x.org, but that doesn't seem to affect the actual problem.

Well, I was able to get type1 to load, at least, so that's not the problem. I'm guessing that xtrap isn't actually required, though I could be wrong about that, of course. I'm starting to think that the problem is something related to that Font error at the very bottom.

[Voltago]

I'm using i810 too and it's working fine (i915GM hardware). Try my xorg.conf (you might want different screen and input options, of course).
Don't worry about font path error messages, they're mostly harmless.

[n0n]

I'm using i810 too and it's working fine (i915GM hardware). Try my xorg.conf

Thanks, will do! I'll let you know...

[n0n]

Thanks, will do! I'll let you know...

Well, thanks again for the input... There's really no difference between your xorg.conf and mine, though, apart from your using the Synaptics device, and having the dual LCD/CRT thing set up, etc. Loaded modules are the same and all that. I've just moved back down to 6.8.99.15 for the time being, I'll give the newer stuff another try over the weekend.

[n0n]

Ah, well it's always the simplest explanation. There were a few libraries my apps were linked against (libXft was a main one) which didn't get built with all the other new X lib packages. Once I had taken care of all that, things became groovy. Thanks for the input, though!

[chtephan]

A lot of dependencies are still missing, but I hand-emerged everything that was missing. I've been using it since I saw the first ebuilds and helped to fix a bunch of annoying bugs. Now it works nearly as well as the old monolithic release. The latest ATI driver snapshot is a bit shaky (borks text mode) and the whiteglass theme package forgets to create a bunch of symlinks but that's it for me. (and it doesn't work with a hardened gcc due to the "-z now" ld flags, undefined references between modules and xserver)

I'm wondering , the Xorg devs don't seem to put a lot of work into the modular release, they're mostly just waiting for people to find and fix the bugs. I hope this will change once the monolithic tree is really dead. I think there's really a lot of cleanup work to be done.

[n0n]

I'm wondering , the Xorg devs don't seem to put a lot of work into the modular release, they're mostly just waiting for people to find and fix the bugs. I hope this will change once the monolithic tree is really dead. I think there's really a lot of cleanup work to be done.

I don't think that's really fair... After all, we're talking about prerelease software which isn't even meant for the general public yet. You'll notice that you've got to dig around quite a bit at xorg.freedesktop.org before you can even find the RC versions. Also note that what's out right now doesn't even seem to be an "official" RC (it's RC0).

Give it a bit of time. It takes a lot of work to do something like this well, and the software's not meant for the end user yet.

[Voltago]

I'm wondering , the Xorg devs don't seem to put a lot of work into the modular release, they're mostly just waiting for people to find and fix the bugs.

And what's wrong with that?
n0n is right. X11R7 is still a RC0, i. e. a technical preview, and shouldn't be used by people who are not prepared to tinker for some time to get everything working. There'll be plenty of time to iron out all those dependency bugs and quirks on the way to release, and even then it will be masked for quite some time in favor of the monolithic xorg-x11, so don't expect a production quality setup right now.

[chtephan]

I didn't mean to be unfair. The next release, the RC1 is meant to be a real release candidate, not just a testing release. Did you look on their bugzilla or mailing lists? There's not much going on. The biggest changes are coming from the monolithic tree and really not much effort is going into the modularization. I'm just saying, not criticising. In fact most of the work is already done and it's working very well. It's just a bunch of details that shows when testing stuff. My impression is that only a few devs have put out the packages but most core devs are still working using the monolithic tree. This is just a sign that they are significantly under-manned and can really use help.

€: Their schedule is perhaps a bit over-optimistic:

http://wiki.x.org/wiki/X11R6970ReleasePlan
https://bugs.freedesktop.org/show_bug.cgi?id=1690

[rapsure]

I am having difficulty getting firefox to run java applets. When I go to a website that has a java applet firefox crashes. I get this:

Code: Select all

brian@rapsure ~ $ firefox
No running windows found

(firefox-bin:18599): Gdk-WARNING **: locale not supported by Xlib

(firefox-bin:18599): Gdk-WARNING **: cannot set locale modifiers
plugin_get_value 1
plugin_get_value 2
current locale is not supported in X11, locale is set to CX locale modifiers are not supported, using defaultINTERNAL ERROR on Browser End: SendRequest: Read of ack failed: 0

System error?:: Success
firefox-bin exited with non-zero status (255)
brian@rapsure ~ $

On all of the other programs that I have been running I am getting the errors.

Code: Select all

brian@rapsure ~ $ gedit

(gedit:18575): Gdk-WARNING **: locale not supported by Xlib

(gedit:18575): Gdk-WARNING **: cannot set locale modifiers
brian@rapsure ~ $ firefox

I would like to get so that java works because then Xorg modular will be functioning just as well as the xorg monolithic was for me. I will also have the updated ATI video drivers which is what I want.

[rapsure]

I am posting a reply to my own message. To fix the locale issue you need to get xorg-macros.m4 and put that file into /usr/share/aclocal/. You can get that from the Xorg cvs server from the macros util or you can just wait until x11-misc/util-macros is updated in portage. Then you need to re-emerge libX11. The problem is that one of the variables is not being set to run a program to parse the text files, and so you end up with no locale support at all. This will effect your computer also if you have the latest libX11 installed. What really needs to happen is to have CVS sync for x11-misc/util-macros.

[Voltago]

I've been wondering about the locale stuff myself and I wonder if it would be better to open a bug for this issue or just wait until the new upstream version comes along...

[rapsure]

I submitted the bug report, and I assigned it to spyderous. I hope it gets resolved quickly

[Sprotte]

dlopen will not load chips driver

From the log:

dlopen: (path) chips_drv.so: undefined symbol: CHIPSMMIOSync

(EE) failed to load module "chips" (loader failed, 7)

Looks like its using the dlloader instead of the ELF loader I used previously. There is however no dlloader use flag anymore.

I am using the vesa driver atm which loads fine.

I researched:

from xorg wiki, "switched to dlib based module loader"

from gentoo hardened xorg guide (I do not use hardened), (some things about -nonow CFLAG and -z now LDFLAG) - my LDFLAGS dont have -z now and in the xserver ebuild there is no trace of the -nonow CFLAG)

from fdo (I think) "dlloader issues" being that (among others) the chips drivers 8+16 overlay mode is not supported, and the workaround being not to use the overlay (I never ever used it, I dont even have kernel framebuffer enabled, I use a VGA text console)

and from various places I gather that some drivers are not working with the dlloader (but were with the ELF loader).

In my old xorg 6.8.2, I _disabled_ the dlloader via USE flag. So I always used the elf loader, and never had problems...

now is there a way to get the xserver ebuild to build it _without_ the dlloader (using the old default ELF loader) OR to set the miraculous -nonow CFLAG (as described in the gentoo hardened xorg guide)?

Should I file a bug somewhere?

Another (small) problem is mouse related, in quake2/icculus I just spin around and the mouse doesnt work. Initially q2 aborted with a message about libXxf86dga missing, so I emerged that. Now the game starts, but mouse input is borked. Quake1 works, as well as wine/starcraft. (this bug is obviously less important)

Otherwise all my apps work OK, firefox et al (GTK2 apps) initially complained about missing libXinerama and Xrandr, which I emerged to solve the problem. Of course, I dont use xinerama. I should probably just reemerge them without. (tested with recompiling openbox, libs are no longer missed)

All in all, it works. Even loads a bit faster I think. But I need the chips driver.

[n0n]

now is there a way to get the xserver ebuild to build it _without_ the dlloader (using the old default ELF loader)

I don't think so... In spyderous' docs for building modular X, he mentions that if you're going to pull any files from your old xorg which aren't in the modular builds yet, that you should be sure to build the old xorg with dlloader.

OR to set the miraculous -nonow CFLAG (as described in the gentoo hardened xorg guide)?

Dunno about that...

Should I file a bug somewhere?

I imagine it'd be best to file it onto bugs.gentoo.org and have spyderous send it upstream if necessary, etc. Wouldn't want to flood the main xorg devs if the problem turns out to be just something in the way Gentoo's building it.

[Sprotte]

I read the guide, but I dont plan to use any old parts from 6.8.2.

well. is there any way to build the xorg-server with the elfloader instead of the dlloader?

Is it relevant if I have pic and/or pie use flags set?

"nm -D chips_drv.so" tells me that CHIPSMMIOSync is undefined (U). There are quite a lot of "U" in the list. I am not gosu enough to really understand that kind of stuff... can that be the problem? should not dlopen just ignore that? If I understood correctly, that is what the -nonow flag is good for.

How to make the server and all modules build with the -nonow CFLAG? Should I just add that to the ebuild?

[n0n]

I read the guide, but I dont plan to use any old parts from 6.8.2.
well. is there any way to build the xorg-server with the elfloader instead of the dlloader?

I just brought up the 6.8.2 stuff to illustrate that it's likely that dlloader is the only supported method right now. I could be wrong, of course, I'm by no means an expert on the newer Xorg stuff. I'm guessing that it's just not supported anymore. The later 6.8.99.x ebuilds didn't support it, either. You could always make up a local ebuild yourself and try putting some of the old dlloader stuff back in. I don't know if you'd have to do it for packages other than xorg-server as well. The bit from the 6.8.99.14 ebuild looks like:

Code: Select all

            if use dlloader; then
                einfo "Setting MakeDllModules to YES."
                echo "#define MakeDllModules    YES" >> ${HOSTCONF}
                if has_hardened; then
                    echo "#define HardenedGccSpecs YES" >> ${HOSTCONF}
                fi
            else
                einfo "Setting MakeDllModules to NO."
                echo "#define MakeDllModules    NO" >> ${HOSTCONF}
            fi

Is it relevant if I have pic and/or pie use flags set?

/me doesn't know about that at all.

"nm -D chips_drv.so" tells me that CHIPSMMIOSync is undefined (U). There are quite a lot of "U" in the list. I am not gosu enough to really understand that kind of stuff... can that be the problem? should not dlopen just ignore that? If I understood correctly, that is what the -nonow flag is good for.

I'll continue being helpful by saying that I've got no clue about what -nonow would do. The undefined symbol could certainly be a problem if that symbol's not defined in some other library. Is there some other chips-related .so lying around which may define that symbol?

[n0n]

In other news, I've noticed something very odd about my modular X install. My copy-on-select/paste-on-middle-button doesn't seem to actually work. Nothing gets pasted when I click on the middle button. I've checked with xev, and X is registering the the button clicks properly.

Is there some extra library which has to be installed for this to work?

[Piper Dawn]

Before I submit this as a bug, I thought I'd run it past the forum:

I can switch back to a command console with Ctrl+Alt+F* just fine, but as soon as I go back to the X window the computer hangs. My normally centred background is aligned to the top-right of the monitor, and neither conky nor fluxbox are shown. The screen blanks out a few seconds later and the system won't respond to any input (such as Ctrl+Alt+Backspace).

Is anybody else having this problem? It seems to be a showstopper that should have been picked up by now, but I'm willing to accept it as an error in my (admittedly quite clumsy) installation.

[Phlogiston]

Before I'll try this modular thing... Is anyone out there using this with nvidia driver? Got it anyone to work?

Greets

[n0n]

Seems to be a showstopper that should have been picked up by now, but I'm willing to accept it as an error in my (admittedly quite clumsy) installation.

When things like that happen, it's generally a problem with the video driver being used at the time. What driver are you using?