Arch Linux

JDSumrall

Member

Registered: 2019-05-11

Posts: 3

Re: Display Manager fails, causes black screen with blinking cursor

Can you go to /usr/share/X11/xorg.conf.d and tell me what conf files are there?

seth

Member

Registered: 2012-09-03

Posts: 51,056

Re: Display Manager fails, causes black screen with blinking cursor

@Ar, your root dir ("/") should not belong to your user, but root:root
a) fix that
b) depending on the cause other ownership/permission might have gone wrong. Any idea what caused that?

Your X11 server in post #16 insta-terminates (cleanly), likely because xinitrc calls twm and esp. xterm as the session keeping process. Do you have xterm installed? (pacman -Qi xterm)
It defaults to the AMD chip, but that seems fine as apparently the internal display is wired to it.

I could imagine that this reverse-prime scenario is the cause for the failure of lightdm & gdm. On which one do you currently focus?

In any event, we should establish a functional display server first, ie. install xterm or adapt the ~/.xinitrc to run something you've actually available.

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Ar

Member

Registered: 2019-04-14

Posts: 16

Re: Display Manager fails, causes black screen with blinking cursor

Thanks @JDSumrall.  The files are:  10-quirks.conf and 40-libinput.conf.

Can you go to /usr/share/X11/xorg.conf.d and tell me what conf files are there?

Ar

Member

Registered: 2019-04-14

Posts: 16

Re: Display Manager fails, causes black screen with blinking cursor

Thanks again.  I am not sure "/" belongs to user.  When I do ls -lh /, I get all directories owned by root:root.

If that is a less accurate way to determine ownership than stat \, please let me know how to fix?  I honestly don't know what would have messed the ownership/permissions, I just did a straight install.

So xterm was not installed.  I just installed it and rebooted just to check, but no joy (alternating black/backlit). 

Regarding lightdm and gdm, I tried both on Arch.  I don't have a strong preference for either, but it is now setup for GDM. 

I should mention that I may have had both gdm and lightdm enabled at the same time.  I did

sudo systemctl disable lightdm.service

, and the result was that now on boot it goes straight to a non-graphical login (console) without flailing on blakscreen.  I think I may be close....

@Ar, your root dir ("/") should not belong to your user, but root:root
a) fix that
b) depending on the cause other ownership/permission might have gone wrong. Any idea what caused that?

Your X11 server in post #16 insta-terminates (cleanly), likely because xinitrc calls twm and esp. xterm as the session keeping process. Do you have xterm installed? (pacman -Qi xterm)
It defaults to the AMD chip, but that seems fine as apparently the internal display is wired to it.

I could imagine that this reverse-prime scenario is the cause for the failure of lightdm & gdm. On which one do you currently focus?

In any event, we should establish a functional display server first, ie. install xterm or adapt the ~/.xinitrc to run something you've actually available.

seth

Member

Registered: 2012-09-03

Posts: 51,056

Re: Display Manager fails, causes black screen with blinking cursor

stat tells you the stats for the path you issued, so "stat /" says what "/" looks like - the permissions of the subdirs are irrelevant.
How exactly did you install archlinux?

About fixing it: "man chown"

About the login success: installing xterm would match the attempts to run "startx" from the multi-user.target (the non graphical login)

About what is or not enabled as services:

systemctl list-unit-files --state=enabled

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

Ar

Member

Registered: 2019-04-14

Posts: 16

Re: Display Manager fails, causes black screen with blinking cursor

Honestly, it was 4 weeks ago now, so I don't remember exactly what I did.  But I followed the Arch instructions.  Regarding chown for "/", of course:  my mind goes to recursive, so I just blanked for a second for some reason.

lorn10

Member

Registered: 2021-03-10

Posts: 3

Re: Display Manager fails, causes black screen with blinking cursor

At first, a hi to all!

Okay folks, here follows now a little epilogue to this quite interesting topic. Maybe this addendum will "enlight" the whole situation here somewhat better.

Right at the beginning it must be said that Apple never ever intended to use the Intel iGPU in the iMac 12,2 model mentioned here. This is effectively true for all iMac models which comes with any sort of (unofficial) dual-GPU functionality. Not one single iMac model was ever advertised by Apple with such a feature, - in contrast to the Macbook models. For Apple, the Intel iGPU is simple not present at the iMac models. Why the iGPU is under native UEFI mode still available is somewhat paradox, it should be disabled at firmware level. This is exactly the case when Linux (and Windows) is booted through the CSM BIOS emulation. No Intel iGPU, nowhere. Whatever, this special Apple behavior in this matter should be somehow a warning if someone wants to experiment with the Intel iGPU on those systems.

Just to be clear, - I don't want to blame here the original OP of this thread. In his case, it seems that the underlying archlinux config (or the kernel) simply had (always) tried to use the wrong (Intel) GPU instead of the AMD Radeon GPU. This then failed, because it must fail. It looks that Apple wants that it fails.

Whatever, what's now going on? First we look at all present GPUs:

*-display
       description: VGA compatible controller
       product: Whistler [Radeon HD 6730M/6770M/7690M XT] [1002:6740]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002]
       physical id: 0
       bus info: pci@0000:01:00.0
       version: 00
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi vga_controller bus_master cap_list rom
       configuration: driver=radeon latency=0
       resources: irq:50 memory:90000000-9fffffff memory:a8800000-a881ffff ioport:2000(size=256) memory:a8820000-a883ffff
*-display
       description: Display controller
       product: 2nd Generation Core Processor Family Integrated Graphics Controller [8086:102]
       vendor: Intel Corporation [8086]
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 09
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm bus_master cap_list
       configuration: driver=i915 latency=0
       resources: irq:49 memory:a8000000-a83fffff memory:a0000000-a7ffffff ioport:3000(size=64)

As we can see, in contrast to almost all "normal" dual-GPU systems, the main GPU 0 is the AMD GPU and not the Intel iGPU which is effectively GPU 1. A further view into dmesg reveals an other interesting entry:

[    1.279421] i915 0000:00:02.0: BAR 6: can't assign [??? 0x00000000 flags 0x20000000] (bogus alignment)
[    1.279422] [drm] Failed to find VBIOS tables (VBT)

So it seems that the Intel HD Graphics 2000 Sandy Bridge iGPU is not properly configured which indicates that it cannot work as it should. There is also another note present:

[    1.030982] [Firmware Bug]: ACPI(GFX0) defines _DOD but not _DOS

What now looks like a bug is a bug but this also confirms that a basic dual-GPU support, represented by the _DOD flag, is available. This is a good message, - if I interpret it correctly.

Unfortunately, even if the Intel i915 iGPU kernel driver issue can be resolved, there exist another problem:

libGL error: Different GPU, but blitImage not implemented for this driver
libGL error: failed to load driver: i965

That message always appears when an application is started though CLI with the DRI_PRIME=1 parameter (e. g. Firefox). The Intel i965 driver misses the "blitImage" feature which is needed on (some) dual-GPU systems. When the use of the second GPU is enforced with "DRI_PRIME=1" in "/etc/environment" the X server crashes right after a re-login is performed. This represents almost exactly the situation of the OP described at the beginning of this thread. However, I have opened a bug report regarding this Intel i965 limitation here:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4368

So that's it for the moment. Maybe an advanced archlinux user is able to get the Intel iGPU working as soon as Intel has implemented the missing "blitImage" function.

Last edited by lorn10 (2021-03-11 14:46:08)