On Wed, 2015-07-08 at 17:10 +0100, Emil Velikov wrote:
On 8 July 2015 at 14:55, Alex Deucher alexdeucher@gmail.com wrote:
On Wed, Jul 8, 2015 at 9:53 AM, Steven Newbury < steve@snewbury.org.uk> wrote:
On Wed Jul 8 14:20:28 2015 GMT+0100, Alex Deucher wrote:
On Wed, Jul 8, 2015 at 8:58 AM, Steven Newbury < steve@snewbury.org.uk> wrote:
On Tue Jul 7 15:12:28 2015 GMT+0100, Alex Deucher wrote:
On Tue, Jul 7, 2015 at 9:46 AM, Steven Newbury < steve@snewbury.org.uk> wrote: > > I've tried an xserver-1.16, and ddx, libdrm without LTO > and with > gcc4.9. Exactly the same thing. I wondered whether the > unused i810 > could be interfering but triggering a device "remove" > before starting > X made no difference. > > I'm a bit of a loss. I suppose I could try writing a > simple test for > drmSetInterfaceVersion(). At least that should > determine whether the > xserver/ddx is in the clear. > > Any other ideas? >
Can you start a non-X runlevel and start X manually as root (assuming you are using a login manager now)?
My test program worked fine. I considerably improved it over the version I posted. I'll send it to the list when I get back.
I removed the drmSetInterfaceVersion() from radeon_kms.c and it got much further. Starting Xserver as root apparently started normally, according to the log, although there was a permission denied error on mode set during init. I don't know whether it was related or not, but the display then hung with a non-blinking cursor. Strange to get a permission denied as root!
Starting GNOME via gdm gives a working slow X session but for some reason only uses sw dri even though the Xorg log shows r200 DRI2 as initialized. Perhaps it's a config error somewhere.. ?
startx as a regular user just works!
But mutter doesn't, perhaps that's why a gnome session isn't working. It just gives the following error: Cogl-ERROR **: Failed to create texture 2d due to size/format constraints
Mutter is supposed to work on r200, right?
IIRC it tries to use a render buffer format that's not supported by the hw.
Is there anything to be done about it? Have to use a different wm/compositor?
Another wm or compositor may help.
Any idea why removing the call from radeon_kms.c worked?
No idea.
From a quick look at the actual implementation drmSetInterfaceVersion is not something that we want/need to use with KMS drivers.
In general the original issue sound like the drm driver is not (fully) loaded before the xserver/ddx kicks in. Additionally it may be a race condition if something else (plymouth) is using the device. In the latter case DRM_MASTER might still be held by $(other_app), thus attempting to either SetInterfaceVersion or do any modeset operation will fail.
Sitting on a KMS console, "systemctl start gdm", no plymouth installed. It's just during Xserver initialisation that drmSetInterfaceVersion() fails. AFAIK Xserver startup is entirely single process, single thread. I've written a little test utility which works fine on the system in question.
Compile attached file with: gcc -O2 -o test-drm test-drm.c $(pkg-config --cflags libdrm) $(pkg -config --libs libdrm)
Personally I would add a healthy amount of printk/printf though the kernel drm + radeon and the ddx.
I guess it doesn't really matter since patching out the code "fixes" it...