Yes, that will work too. Some slight reformatting is needed to present it in the Xorg config file though. For example, I get the following reported…
bus-ID: 00:02.0
This then gets reformatted for Xorg use with colon-separated values…
PCI:00:02:0
I retested with my laptop (I happened to be looking at the /sys/bus/pci/devices directory when I ran the command, but that is not relevant to this):
linux:/sys/bus/pci/devices # inxi -Gxx | grep bus-ID
bus-ID: 00:02.0 chip-ID: 8086:0166
Using that (and advise from your post) I then updated the /etc/X11/xorg.conf.d/50-device.conf file to read:
Section "Device"
Identifier "devname"
Driver "fbdev"
BusID "PCI:00:02:0"
EndSection
I rebooted and the FBDEV driver appeared to load without error (as previous there was an error with a note the FBDEV was falling back to an old probe for FBDEV (or something like that).
There is still a lot more I need to learn here.
Hopefully this meandering of mine has been helpful and not disruptive to maeller71 .
.
That reads like progress Lee. Not something I’ve had to use/experiment with for a long time. Hopefully, the OP can get it working as well.
FWIW, the vesa driver should be able to be used in the same manner.
Thank you so much for your very helpful response. Now I am able for the first time in a long time to log in to my current Linux system in graphical mode.
Here is how it currently works for me:
(1) I modified 50-device.conf to have the following active code:
Section “Device”
Identifier “Default Device”
Driver “fbdev”
EndSection
(2) At each new start of Linux I press “e” key at the Grub2 boot screen and add the following kernel boot parameter:
nomodeset
Note that without doing (2) - which basically disables KMS in latest Linux kernels as believe I learned recently - I still get the blank screen at boot and the system freezes.
So now I have at least a working system- thank you! The resolution, however, is only 800x600 while the display can support a full-HD (1920x1080) resolution. Is there any way to tell “fbdev” to use the full-HD resolution?
Coming back to the original problem. It looks like that this HP BIOS F.19 Rev.A update to fix something with the HP Envy x360 laptop screen has made my system (I’m using Kernel 4.18.5-1) having issues with built-in KMS. I’m guessing here since I’m not the expert.
The “fbdev” in 50-device.conf file is a work-around but I think we should address the original problem, too. Do you have any advice for me how to proceed next?
That is good to know and I note that you did not need to include the BusID explicitly.
(2) At each new start of Linux I press “e” key at the Grub2 boot screen and add the following kernel boot parameter:
nomodeset
Note that without doing (2) - which basically disables KMS in latest Linux kernels as believe I learned recently - I still get the blank screen at boot and the system freezes.
That can be automated by modifying the GRUB boot line permanently if desired.
So now I have at least a working system- thank you! The resolution, however, is only 800x600 while the display can support a full-HD (1920x1080) resolution. Is there any way to tell “fbdev” to use the full-HD resolution?
No, the framebuffer is a basic driver with limited display resolution support. You may be able to get better display resolution using the vesa driver.
The “fbdev” in 50-device.conf file is a work-around but I think we should address the original problem, too. Do you have any advice for me how to proceed next?
Yes, this is just a workaround to give you a basic working graphical environment. Hopefully, others can advise as to how to get the amdgpu driver working for you.
Ok - how do I need to modify the 50-device.conf file (or any other file) to switch to vesa driver? Sorry for this simple question but I just want to make sure I get it right.
Section “Device”
Identifier “Default Device”
Driver “fbdev”
EndSection
Change fbdev to vesa
I did that and the system didn’t start in graphics mode but presented me with login prompt in text mode. After reverting back to “fbdev” I could start in graphics mode again … but with 800x600 resolution only.
Do you have ‘xf86-video-vesa’ installed?
It may also not be compatible with your hardware perhaps. Analysis of the Xorg log would be needed.
Can you supply your graphics hardware details please?
inxi -Gxx
Yes - I do have “xf86-video-vesa” installed.
Here is the output of inxi -Gxx:
Graphics:
Card-1: AMD Raven Ridge [Radeon Vega Series / Radeon Vega
Mobile Series]
driver: N/A bus ID: 04:00.0 chip ID: 1002:15dd
Display: x11 server: X.Org 1.20.1 driver: none
unloaded: fbdev resolution: 800x600~75Hz
OpenGL: renderer: llvmpipe (LLVM 6.0 128 bits)
v: 3.3 Mesa 18.1.7 compat-v: 3.1 direct render: Yes
I don’t think I can help with further FBDEV, Vesa, nor AMDGPU driver tuning. Hopefully others on this forum may be able to. wrt the original problem, my suspicion is you need to raise 1 and possibly 2 bug reports to proceed, wrt getting the radeon or amdgpu driver to work.
A bug report on openSUSE Tumbleweed is IMHO needed, so to flag this problem with openSUSE. There is guidance here on how to do that: https://en.opensuse.org/openSUSE:Submitting_bug_reports . You can use your openSUSE forum username and password to log on to openSUSE bugzilla. However since the problem is likely upstream, there is likely no fix coming from openSUSE, unless one of the openSUSE packagers happens to be a graphic driver developer for your hardware. I suspect that not likely.
Hence I think a second bug report may be needed, this one on https://bugzilla.kernel.org/ . I’ve never raised such myself, so I can’t help there with specifics.
Its possible there is already a bug report on this on https://bugzilla.kernel.org/, but I suspect not. I note these bug reports:
-
Bug 198715 - ELAN touchscreen in HP Envy x360 15-bq100 (up to date bios) not working on kernel 4.15, or 4.16-rc1
Bug 196683 - Random Soft Lockup on new Ryzen build <<< but that was raised in year 2017 before the BIOS update that impacted your PC.
In any bug report, you can note :
- PC worked with Tumbleweed kernel 4.18.5-1-default before the BIOS F.19 Rev.A update
- PC nominally freezes during boot with Tumbleweed kernel 4.18.5-1-default after the BIOS F.19 Rev.Aupdate
- PC freezes with Tumbleweed kernel 4.18.5-1-default if boot to run level-3 via grub after the BIOS F.19 Rev.A
- after BIOS F.19 Rev.A update PC boots with Tumbleweed kernel 4.18 4.18.5-1-default to run level-3 if specify grub boot code ‘nomodeset’
- after BIOS F.19 Rev.A update PC boots with Tumbleweed kernel 4.18.5-1-default to Xwindows if specify grub boot code ‘nomodeset’ and also specify ‘fbdev’ in 50-device.conf file.
- after BIOS F.19 Rev.A update PC boots with LEAP-15.0 kernel ( 4.12 - ???) to Xwindows.
Please fill in the ( 4.12 - ??? ) with the correct version.
There were changes made between the LEAP-15.0 kernel and the Tumbleweed kernel which are incompatible with the recent HP BIOS update.
Possibly armed with that information, you can then be asked to provide information from the appropriate log files of both your LEAP-15.0 system and your Tumbleweed system, so that they experts can narrow down the problem, and then maybe come up with a solution.
Its possible the solution may lay with HP, and not GNU/Linux kernel, and I hope that not the case, as manufacturers nominally do not consider it worth their while to fix their systems to work with GNU/Linux.
.
[SOLVED]
After upgrading to the latest Kernel version 4.18.8-1 the HD graphics works again as before.
Thats great news.
coud you maybe try:
rpm -q kernel-default-4.4.155-68.1.x86_64 --changelog > updates.txt
but instead of 4.4.155-68.1.x86_64 substitute your kernel… it could be:
rpm -q kernel-default-4.18.8-1.x86_64 --changelog > updates.txt
or possibly the kernel-default (?) version is a bit different.
Open the file “updates.txt” with a text editor. That will tell you what has changed. Check what it has for the 4.18.8-1. Does it mention anything about graphics ?
I’m curious as to what is different.
.
Out of curiousity, I downloaded kernel-default-4.18.8-1.3.x86_64.rpm and checked to see what had changed since kernel-default-4.18.5. There were a MASSIVE number of changes. Its hard to see what fixed this:
I noted the following in Linux 4.18.8
- drm/amdgpu: Don't warn on destroying a pinned BO (bnc#1012628).
- drm/amdgpu: Warn and update pin_size values when destroying a pinned BO (bnc#1012628).
- drm/amdgpu: Make pin_size values atomic (bnc#1012628).
- drm/amdgpu: Keep track of amount of pinned CPU visible VRAM (bnc#1012628).
...
- drm/amdgpu: fix incorrect use of drm_file->pid (bnc#1012628).
- drm/amdgpu: fix incorrect use of fcheck (bnc#1012628).
- drm/amdgpu:add VCN booting with firmware loaded by PSP (bnc#1012628).
- drm/amdgpu:add VCN support in PSP driver (bnc#1012628).
- drm/amdgpu:add new firmware id for VCN (bnc#1012628).
- drm/amdgpu:add tmr mc address into amdgpu_firmware_info(bnc#1012628).
- drm/amdgpu: update tmr mc address (bnc#1012628).
- drm/amd/display: Check if clock source in use before disabling (bnc#1012628).
- drm/amd/display: Pass connector id when executing VBIOS CT (bnc#1012628).
...
- drm/amd/display: Report non-DP display as disconnected without EDID (bnc#1012628).
- drm/amd/display: Use requested HDMI aspect ratio (bnc#1012628).
- drm/amd/display: update clk for various HDMI color depths (bnc#1012628).
- drm/amd/display: Don't share clk source between DP and HDMI(bnc#1012628).
- drm/amd/display: fix type of variable (bnc#1012628).
- drm/amd/pp/Polaris12: Fix a chunk of registers missed to program (bnc#1012628).
- drm/amd/powerplay: fixed uninitialized value (bnc#1012628).
- drm/amd/pp: Convert voltage unit in mV*4 to mV on CZ/ST (bnc#1012628).
- drm/amdgpu: Fix RLC safe mode test in gfx_v9_0_enter_rlc_safe_mode (bnc#1012628).
- drm/amdgpu: fix a reversed condition (bnc#1012628).
- drm/amdgpu: update uvd_v6_0_ring_vm_funcs to use new nop packet (bnc#1012628).
...
- drm/etnaviv: fix crash in GPU suspend when init failed due to buffer placement (bnc#1012628).
...
- drm/amd/display: Read back max backlight value at boot (bnc#1012628).
...
- drm/amd/display: Guard against null crtc in CRC IRQ (bnc#1012628).
...
There are many more in 4.18.8, 4.18.7 and 4.18.6. It exceeds my competence to figure which was the one that fixed your issue. … But it was fun looking, even if I did not succeed.
Again - glad its working again.
Its after the fact … with my curiousity driving me (curious as to what was the fix ? ) - I still have not figured out which of the updates addressed the issue.
I note other threads now, where you were not alone: Raven Ridge (mobile?) Linux users beware of BIOS updates where in the quoted case to solve that issue, the OP in the link managed to get their system (openSUSE Tumbleweed) working again by adding a repository and installing kernel 4.19-rc2 - so no stable release yet. 4.18.5 was previously installed which didn’t work.
.
I may have found the bug report that lead to the kernel fix … Bug 107880 - Regression: System fails to boot on raven ridge 4.18 vs 4.19 rc
When I get time, I may again go through the list of updates to the openSUSE kernel where this was addressed.
FWIW, since kernel update provided the fix for the root problem, time spent trying to improve VESA or FBDEV performance, or get either to work at all, via /etc/X11/* and/or xrandr, is time wasted.
Both VESA and FBDEV are very slow, very crude drivers that do not depend on KMS and cannot support any native widescreen or high resolution video modes. They are suitable only for troubleshooting purposes, or for people using X only as some sort of convenience (the GUI version of YaST2 in particular) to compensate for lack of understanding how to solve problems using the cmdline. Both are all but useless for popular desktop environments and applications, web browsing and videos in particular.
Appending nomodeset on the kernel cmdline is primarily a kludge to enable troubleshooting whatever it is that is preventing (competent, aka Intel, Amdcpu, Radeon, Nouveau & Modesetting) FOSS X drivers from loading and/or causing black screens and/or lockups. Competent FOSS drivers depend on KMS, which nomodeset explicitly disables. The primary exception to this rule applies to NVidia users who use NVidia’s proprietary X drivers, which depend on having KMS disabled.
Whenever nomodeset is used to prevent black screens or lockups, the first order of business once booted should be determining how to dispense with its need, not to try to make FBDEV or VESA work better (if at all), since “better” with them can barely approach tolerable, never optimal.
It is this OP’s good fortune that latest kernel provided a solution so quickly. 
What exactly precipitated installation of the BIOS update that precipitated this thread? Usually PC and motherboard manufacturers recommend not installing the latest BIOS unless it is known to solve a particular problem that the product’s owner is actually experiencing.
I find it educational sometimes, to go through these bug reports, and look at the work arounds applied, until the fix eventually released. In this case, in reading the above bug report, I note there was a suggested work around that we did not think of, which was in the grub boot menu, to to prevent the driver from loading by passing:
modprobe.blacklist=amdgpu
and then, if that gave a successful boot, to then once in Xwindows try to generate a list of errors by trying to load the driver (which I assume would have failed to load the driver but would have given the errors):
sudo modprobe amdgpu
Further, it was noted that there was possibly an issue with the VCN microcode loading. A test (in the user’s case who was reporting the bug) noted the kernel boot option:
amdgpu.ip_block_mask=0xff
allowed a boot.
Again, something not seen by myself in this thread (of course I did not discover the bug report until later).
This has been educational for myself. It is this sort of visibility that is one of the things that I really like about GNU/Linux.
.
Yes, I would hope that the OP understands that was just a means to gaining a minimal working graphical environment…to help facilitate further troubleshooting steps etc.