kmscon fails to show anything without --all-gpus about kmscon

[bluetech]

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

[dvdhrm]

I pushed f5a98b0 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)