kmscon fails to show anything without --all-gpus

[bluetech]

Hi David,

Starting ./kmscon (current HEAD: 9d2018f52184709bc72b58126fa23354c3316c09) doesn't show anything, besides some strange residual text content from a previous run on the top of the screen (e.g. some "ran $ ls" prompt cut in the vertical middle, which is probably what was there before).

The machine on which this happens has an nvidia 9600GT with the nvidia driver (yea, sorry). kmscon uses --fbdev here. Here is the lspci for it:

01:00.0 VGA compatible controller: NVIDIA Corporation G94 [GeForce 9600 GT](rev a1) (prog-if 00 [VGA controller]) Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f6000000 (32-bit, non-prefetchable) [size=16M] Memory at e0000000 (64-bit, prefetchable) [size=256M] Memory at f4000000 (64-bit, non-prefetchable) [size=32M] I/O ports at c000 [size=128] [virtual] Expansion ROM at f7000000 [disabled] [size=512K] Capabilities: Kernel driver in use: nvidia

There are no other GPUs on this machine. Kernel version is 3.5.4.

Bisection: 5be89722708f5071ff6630fad1331d3f6d149ae3 is the first bad commit commit 5be89722708f5071ff6630fad1331d3f6d149ae3 Author: David Herrmann dh.herrmann@googlemail.com Date: Sat Oct 27 18:00:27 2012 +0200

kmscon: add --primary-gpu-only and --all-gpus options

By default, kmscon now only uses primary und auxiliary displays. All
uncategorized displays are ignored. This fixes problems with dual-GPU
systems.

--primary-gpu-only makes kmscon not use any auxiliary displays. --all-gpus
makes kmscon also use uncategorized displays.

Signed-off-by: David Herrmann <dh.herrmann@googlemail.com>

:040000 040000 2540782870b28321cccd9f468c36324c0001f45b 1a2cfa8fd88f08160c2fc5d3f6649efbbae4d4a0 M src

Passing --all-gpus makes it work normally.

Here is a --debug log: https://gist.github.com/3965344

[bluetech]

Here's an proper log, don't know what was up with the previous one: https://gist.github.com/3965365

[dvdhrm]

I pushed f5a98b0c6b6d26e5ceada399fe8e56734ed53dea for now. This should fix it. However, I want to fix this for real so can you give me the output of "ls -l /sys/class/graphics/fb0/"?

[bluetech]

Here:

ran@ran:~$ ls -l /sys/class/graphics/fb0/ total 0 drwxr-xr-x 2 root root 0 Oct 21 00:02 power/ -rw-r--r-- 1 root root 4.0K Oct 27 19:35 bits_per_pixel -rw-r--r-- 1 root root 4.0K Oct 27 19:35 blank -rw-r--r-- 1 root root 4.0K Oct 27 19:35 bl_curve -rw-r--r-- 1 root root 4.0K Oct 27 19:35 console -rw-r--r-- 1 root root 4.0K Oct 27 19:35 cursor -r--r--r-- 1 root root 4.0K Oct 27 19:35 dev lrwxrwxrwx 1 root root 0 Oct 27 19:35 device -> ../../../vesafb.0/ -rw-r--r-- 1 root root 4.0K Oct 27 19:35 mode -rw-r--r-- 1 root root 4.0K Oct 27 19:35 modes -r--r--r-- 1 root root 4.0K Oct 27 19:35 name -rw-r--r-- 1 root root 4.0K Oct 27 19:35 pan -rw-r--r-- 1 root root 4.0K Oct 27 19:35 rotate -rw-r--r-- 1 root root 4.0K Oct 27 19:35 state -r--r--r-- 1 root root 4.0K Oct 27 19:35 stride lrwxrwxrwx 1 root root 0 Oct 20 22:59 subsystem -> ../../../../../class/graphics/ -rw-r--r-- 1 root root 4.0K Oct 20 22:59 uevent -rw-r--r-- 1 root root 4.0K Oct 27 19:35 virtual_size

[dvdhrm]

I didn't expect you to use vesafb, so this didn't show the information I needed. Ok, lets try something more verbose. Can you run:

udevadm info --query=all --path=/sys/class/graphics/fb0

(Note that you must not use a slash as last character!) In fact, I am interested in the PCI-id of the GPU fb0 is running on. And more important, I need a solid way to retrieve this PCI-ID.

[bluetech]

Here (sorry if I can't provide more useful info, I don't know this stuff):

ran@ran:~$ udevadm info --query=all --path=/sys/class/graphics/fb0 P: /devices/platform/vesafb.0/graphics/fb0 N: fb0 E: DEVNAME=/dev/fb0 E: DEVPATH=/devices/platform/vesafb.0/graphics/fb0 E: ID_FOR_SEAT=graphics-platform-vesafb_0 E: ID_PATH=platform-vesafb.0 E: ID_PATH_TAG=platform-vesafb_0 E: MAJOR=29 E: MINOR=0 E: SUBSYSTEM=graphics E: TAGS=:seat: E: USEC_INITIALIZED=72446

Here is a more detailed lspci -vvv:

01:00.0 VGA compatible controller: NVIDIA Corporation G94 [GeForce 9600 GT](rev a1) (prog-if 00 [VGA controller]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at f4000000 (64-bit, non-prefetchable) [size=32M] Region 5: I/O ports at c000 [size=128] [virtual] Expansion ROM at f7000000 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [68] MSI: Enable- Count=1/1 Maskable- 64bit+ Address: 0000000000000000 Data: 0000 Capabilities: [78] Express (v2) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <4us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <512ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- Capabilities: [128 v1] Power Budgeting <?> Capabilities: [600 v1] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Kernel driver in use: nvidia

[dvdhrm]

Argh, I hate this. The problem is actually not that easy to solve. Let me describe what problems we have:

The linux kernel provides fbdev, DRM and v4l2 (video 4 linux 2) video drivers. Unfortunately these aren't mutually exclusive. Even on a per-device level, we might end up with multiple drivers for a single device. For now, as an application developer, I need to choose which API to use and use it exclusively. However, I wanted to change this mess with kmscon. I want to be able to use fbdev, DRM and v4l2 simultaneously. This works for me with internal intel-DRM and external DisplayLink fbdev devices. But I must never use two APIs that control the same device simultaneously. That's why I added some heuristics which try to detect devices that are known to have multiple kernel drivers. Unfortunately, the kernel doesn't provide this information itself, so we need to use these ugly heuristics. Btw., this gets a lot more ugly if you consider multi-GPU systems that modern laptops are. These contain multiple-GPUs that are reported as different devices to user-space. However, they might not be able to use simultaneously because they share display-controllers. This is why I added the PRIMARY logic.

So what heuristics do we have in kmscon now? By default kmscon lists all DRM and fbdev devices and provides them to the application. Devices can be marked as PRIMARY, DRM_BACKED and AUXILIARY (or any combination of them):

• All DRM drivers provide fbdev devices for backwards compatibility. fbdev devices that are driven by DRM drivers are detected by kmscon and only used in non-DRM mode. They are marked as DRM_BACKED.
• The PCI Bus is queried for "boot_vga" flags and all DRM devices that have the given PCI-Bus-ID are marked as PRIMARY.
• USB hotpluggable devices that are independent of any internal GPUs are marked as AUXILIARY.

Now, we need some flags which tell kmscon when to use a device. The following checks are done in sequential order. So for a device to be used, it needs to pass all tests:

• kmscon does never use DRM devices and DRM_BACKED devices simultaneously. This doesn't make any sense and this detection does work very reliably. With --fbdev you can make kmscon ignore all DRM devices but use DRM_BACKED instead. With --no-fbdev (default), kmscon ignores DRM_BACKED fbdev devices and uses DRM devices instead.
• If --all-gpus and --fbdev are not specified, the following checks are performed:
  • Devices not marked as AUXILIARY or PRIMARY are ignored
  • If --primary-gpu-only is given, devices not marked as PRIMARY are ignored

So for your case, kmscon detects a vesafb device and cannot mark it as PRIMARY. Therefore, it isn't picked up. So why don't I simply mark vesafb devices as primary? Because vesafb may be used simultaneously with DRM. That means, kmscon cannot use vesafb and a DRM device that controls the system GPU simultaneously. In other words, there is no way to detect whether the vesafb framebuffer is independent of any present GPU. This is why you need to use --fbdev.

But, if your kernel doesn't use DRM, kmscon can set --fbdev automatically during runtime. However, this requires that your kernel is compiled without CONFIG_DRM (or in other words: /proc/dri/ does not exist).

I will try to put this into the man-page I am currently writing so it gets more obvious how this works.

Regards David

[dvdhrm]

Ok, I changed the device handling a lot. If anything is not working, you can use --video-devices=/dev/fb0 to make kmscon use fb0 and avoid all the device-checking logic.

Anyway, could you check whether it works by default now? Btw., running kmscon as ./kmscon -v is often the best way to check for errors, as it shows all the INFO lines but avoids the DEBUG lines that occur with --debug.

[bluetech]

Yes, it does work by default now. Thanks! (also for the extended explanation)