How do I proceed from here?

[splashmac]

startx spits out vesa: refusing to run framebuffer or dri device present

How do I proceed? I want X to start using fbdev, vesa, or my radeon driver. Do I need to edit my xorg confs?

[alexander-n8hgeg5e]

You mean "on dri device present" ?
If you did not create a custom xorg I'd start with
deleting the xorg and then maybe run the xserver
for testing with some debugging args like X -something

[NeddySeagoon]

splashmac,

startx is not expected to be useful without some configuration.
It tries to run three xterms, and xclock all wrapped up in twm.
None of those are installed by default in Gentoo.

A couple of things to help us to help you.

Code: Select all

emerge pciutils wgetpaste 

if you don't have them.

Run

Code: Select all

lspci -nnk

and post the output. That will tell us a bit about your hardware and the kernel drivers in use.
Post the content of use wgetpaste to share the content of Xorg.0.log.
Where that is depends on the user running startx.
It will tell what Xorg did or tried to do when it started.

[splashmac]

lspci and xorg log here
https://bpa.st/WNHQ

[alexander-n8hgeg5e]

lspci and xorg log here
https://bpa.st/WNHQ

Hm basically it tries to load vesa but vesa refuses to run because dri / frambuffer is available
so,... Hm,... best thing would be to have "dri"

Or maybe you only need to enable the "fbdev" driver
(in VIDEO_CARDS)
for the package x11-base/xorg-drivers
I never started an xserver with the "fbdev" driver.
Maybe the xserver refuses to start because it can't take over the
fbdev which is already taken by the console.

Is there some dri/drm kernel driver loaded?
Ok I see, the output of lspci lists no driver for your video card
so probably it's not loaded or so.
Maybe it is there but missing firmware or so,...
You can search the output of dmesg for further information
like so :

Code: Select all

dmesg|grep -i -C5 firmware

you can try diffent words like "dri" or "drm"
if I do it with drm and -C1 it spits out even more stuff like this:

Code: Select all

[  122.059529] nouveau 0000:05:00.0: DRM: DCB conn 03: 00002361                     
[  122.061036] nouveau 0000:05:00.0: DRM: MM: using COPY0 for buffer copies         
[  122.258306] nouveau 0000:05:00.0: [drm] Cannot find any crtc or sizes            
[  122.276693] [drm] Initialized nouveau 1.3.1 20120801 for 0000:05:00.0 on minor 0 
[  122.448300] nouveau 0000:05:00.0: [drm] Cannot find any crtc or sizes            
[  124.795641] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.      

do you have x11-base/xorg-drivers installed ?

Another system with nividia gpu tells this line(and more):

Code: Select all

[  151.418978] [drm] Initialized nouveau 1.3.1 20120801 for 0000:02:00.0 on minor 0 

This tells you it loaded some "drm" driver. I think it is like "dri"
The kernel calls your graphics system like so.
Then I think you need xorg-drivers with
probably USE=libinput to have input
and any of the "VIDEO_CARDS"
This is from a machine (the one with no monitor connected but it has xorg-drivers)
I got this with "eix xorg-drivers" but you can also look into /var/db/pkg/x11-base and look out for a directory "xorg-drivers-some-version" like so: ls /var/db/pkg/x11-base/xorg-drivers-*/

Code: Select all

[I] x11-base/xorg-drivers
     Available versions:  21.1-r2{tbz2} **9999*l {INPUT_DEVICES="elographics evdev joystick libinput synaptics vmmouse void wacom" VIDEO_CARDS="amdgpu ast dummy fbdev freedreno geode i915 intel mga nouveau nvidia omap qxl r128 radeon radeonsi siliconmotion tegra vc4 vesa via virtualbox vmware"}
     Installed versions:  21.1-r2{tbz2}(11:35:20 PM 02/11/2023)(INPUT_DEVICES="libinput -elographics -evdev -joystick -synaptics -vmmouse -void -wacom" VIDEO_CARDS="nouveau -amdgpu -ast -dummy -fbdev -freedreno -geode -i915 -intel -mga -nvidia -omap -qxl -r128 -radeon -radeonsi -siliconmotion -tegra -vc4 -vesa -via -virtualbox -vmware")
     Homepage:            https://wiki.gentoo.org/wiki/No_homepage
     Description:         Meta package containing deps on all xorg drivers

Then you maybe find your kernel config in /proc/config.gz (or similar)
"gz" means you need to decompress it.
so if you want to grep it you can do

Code: Select all

zcat /proc/config.gz|grep -i -E 'drm\w*=[my]'

this tells me my kernel has the nouveau driver as a module

Code: Select all

CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_DISPLAY_HELPER=m
CONFIG_DRM_DISPLAY_DP_HELPER=y
CONFIG_DRM_DISPLAY_HDMI_HELPER=y
CONFIG_DRM_TTM=m
CONFIG_DRM_TTM_HELPER=m
CONFIG_DRM_GEM_SHMEM_HELPER=m
CONFIG_DRM_NOUVEAU=m
CONFIG_DRM_NOUVEAU_BACKLIGHT=y
CONFIG_DRM_VKMS=m
CONFIG_DRM_VIRTIO_GPU=m
CONFIG_DRM_PANEL=y
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=m
CONFIG_DRM_NOMODESET=y

[NeddySeagoon]

splashmac,

Code: Select all

01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600] [1002:71c5]
	Subsystem: Apple Inc. MacBook Pro [106b:0080]

There should be another line there about

Code: Select all

Kernel driver in use: 

Your kernel is missing Radeon support. That will need drm support too.

As its an Apple, does it BIOS boot or is it EFI?

Show us (on pastebins) all of dmesg and the output of

Code: Select all

emerge --info

If you know how to fix your kernel go ahead and do it, if not pastebin your entire kernel config file.

[splashmac]

vesa: Refusing to run, Framebuffer or dri device present line in Xorg log, wouldn't that mean I have to disable Framebuffer in the kernel or dri in the kernel? But if I do have framebuffer and dri in the kernel and vesa is trying to load shouldn't I change the driver from vesa to something else?

[NeddySeagoon]

splashmac,

You can't use VESA on an EFI system. It needs BIOS support and EFI is missing that.
You need drm and radeon in the kernel to get started.

Everything is a framebuffer now. even the 24x80 VGA ' text' console.

[splashmac]

KERNEL Disable legacy framebuffer support and enable basic console FB support
Device Drivers --->
Graphics support --->
Frame Buffer Devices --->
<*> Support for frame buffer devices --->
## (Disable all drivers, including VGA, Intel, NVIDIA, and ATI, except EFI-based Framebuffer Support, only if you are using UEFI)

## (Further down, enable basic console support. KMS uses this.)
Console display driver support --->
<*> Framebuffer Console Support

Doesn't this contradict itself by disabling all drivers including ATI when later you need to enable ATI radeon driver? And can I use the UEFI framebuffer and not use radeon? My radeon is spitting out dots and garbled screen. If I need nomodeset in my refind_linux.conf to not have garbled screen is there an issue with monitor settings?

[alexander-n8hgeg5e]

Hm, I don't know that much about framebuffers in the linux kernel but usually it's ok to enable stuff
while not using it.
I would try to enable everything that could be missing. Then when the kernel is working, you can remove the things you don't need.
Keep your current kernel as backup in case you need it to boot the system.
If your system boots up and you get no display at all then you could use a serial cable
or ssh into it.
Maybe try to enable "drm/dri" things and the 3d accelerated driver for the radeon card.
Then don't forget to compile the xorg-drivers package with the corresponding
flags.

[NeddySeagoon]

splashmac,

There are a lot of hardware specific framebuffer dlivers in the framebuffer menu that are only useful with last millennium GPUs.
They mostly interfere with the operation of the GPU, so must be off.

The exceptions are
VESA, which an only be used on BIAS systems or with BIOS booting.
EFI, which is tied to EFI firmware
and Simple Frame Buffer, which is so simple that in only draws on an existing framebuffer. It has no setup commands.

All the modern Direct Render Manager (DRM) kernel drivers also provide framebuffers at no extra charge. There are the console drivers you should use.

At startup the kernel will normally use EFI/VESA. Neither of these driver try to take over and 'own' the GPU, which is why the others need to be off.
If the GPU is already owned, the DRM framebuffer cannot start.

When all is well, the DRM framebuffer takes over from EFI/VESA. When this switchover occurs, if the DRM framebuffer is broken, console output is lost.

[alexander-n8hgeg5e]

splashmac,

There are a lot of hardware specific framebuffer dlivers in the framebuffer menu that are only useful with last millennium GPUs.
They mostly interfere with the operation of the GPU, so must be off.

The exceptions are
VESA, which an only be used on BIAS systems or with BIOS booting.
EFI, which is tied to EFI firmware
and Simple Frame Buffer, which is so simple that in only draws on an existing framebuffer. It has no setup commands.

All the modern Direct Render Manager (DRM) kernel drivers also provide framebuffers at no extra charge. There are the console drivers you should use.

At startup the kernel will normally use EFI/VESA. Neither of these driver try to take over and 'own' the GPU, which is why the others need to be off.
If the GPU is already owned, the DRM framebuffer cannot start.

When all is well, the DRM framebuffer takes over from EFI/VESA. When this switchover occurs, if the DRM framebuffer is broken, console output is lost.

Thats good to know.
Once I wanted to unload my DRM driver (it was the nouveau driver)
And I had to tell the "vtconsole" to use a dummy frame buffer.
I think this is only possible if you don't need the vtconsole and you are logged in with ssh
or serial cable or something like this. Because if I got it right, "vtconsole" is what allows you to switch
with Alt-FKey through the terminals and is essentially your terminal on your local screen.
It worked like this: (logged in via ssh !)

Code: Select all

echo 0 > /sys/class/vtconsole/vtcon0/bind

and this is how it looks in the sys tree:

Code: Select all

ls  /sys/class/vtconsole

gives

Code: Select all

vtcon0  vtcon1

and

Code: Select all

cat /sys/class/vtconsole/vtcon0/name

gives

Code: Select all

(M) frame buffer device 

and

Code: Select all

cat /sys/class/vtconsole/vtcon1/name

gives

Code: Select all

(M) dummy device 

[NeddySeagoon]

alexander-n8hgeg5e,

For the avoidance of doubt the step

Code: Select all

echo 0 > /sys/class/vtconsole/vtcon0/bind 

detaches the console.
That makes it hard to read until its reattached somewhere else.