- This topic has 81 replies, 7 voices, and was last updated Dec 31-3:11 pm by ant_222.
-
Posts
-
ant_222
FYI, I found that the version of firmware-misc-nonfree in the repos is from 20210315, and the description does not show jasper lake in the description as one of the Intel systems included. It might be that one of the newer versions does.
Yesterday, an upgrade of that package left me with a kernel panick. Before I try it again, how can I make sure I need it, now that Xorg has finally started in the correct resolution?
BobC
I’m no authority on it. I would say checking the repos would be the best idea. Maybe the one you chose wasn’t a newer one for bullseye?
Also, if it is working correctly now, I probably would leave it alone.
You could allow us to have a look at
inxi -GxxYes:
$ inxi -Gxx Graphics: Device-1: Intel JasperLake [UHD Graphics] driver: i915 v: kernel arch: Gen11 ports: active: DP-2 empty: DP-1,HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:4e61 Display: server: X.Org v: 1.20.11 driver: X: loaded: modesetting gpu: i915 display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1280x1024 s-dpi: 96 Monitor-1: DP-2 model-id: RGT 0x1252 res: 1280x1024 dpi: 203 diag: 1168mm (46") OpenGL: renderer: Mesa Intel UHD Graphics (JSL) v: 4.6 Mesa 20.3.5 direct render: YesI’m no authority on it. I would say checking the repos would be the best idea. Maybe the one you chose wasn’t a newer one for bullseye?
Yes, it was sid, because bullseye said it was already up-to-date. During the installation, there were lots of prompts for permission to change various configuration files, some of which I did not allow, perhaps causing the kernel panic.
Also, if it is working correctly now, I probably would leave it alone.
It is the X resolution. I was not proposing to change it, but asked how to make sure the driver is fully functional. What does not work, however, is the framebuffer console. I have only one framebuffer device,
/dev/fb0
which does not seem mapped to any of my virtual terminals, since
echo test > /dev/fb0
has no effect anywhere, nor does fbset. It starts working from within fbterm, but:$ fbset 1280x1024-60 ioctl FBIOPUT_VSCREENINFO: Invalid argumentThat is one of standard Vesa videomodes, present is the fbterm db.
How many framebuffer devices do you have, are they used for your virtual consoles? The classic Framebuffer HOWTO dates back to 2010. Is it obsolete or worth trying?
Did you try the newer bullseye version?
I suggest you post what specs you have highlighting the functionality its supposed to have that you are trying to use. You might get lucky and someone here can help, but you can’t really expect people here to know when none of us has a setup like yours. Have you asked the manufacturer?
I very rarely use the virtual consoles. Once a year maybe, if that.
Did you try the newer bullseye version?
Yes.
I suggest you post what specs you have highlighting the functionality its supposed to have that you are trying to use.
I have asked it in this new thread.
You might get lucky and someone here can help, but you can’t really expect people here to know when none of us has a setup like yours. Have you asked the manufacturer
I seek help here from the software and OS perspective. I double the manufacturer is going to help me setup the Linux framebuffer/DRM, but I will try.
Robin
Just an idea. Sometimes, if proper resolution won’t come up, the monitor itself is the culprit, providing wrong EDID data to the graphics board, due to buggy firmware, keeping the proper resolution from being activated by the graphics card. Luckily this can be fixed by creating a personal EDID file on your system for this broken device. See https://gist.github.com/hinell/0ebaad01b771a70844204f295aaf03b7 for details.
Windows is like a submarine. Open a window and serious problems will start.
Thank you, Robin, I will try your suggestion. Please, continue discussion in the framebuffer-related thread. This one was for my X video mode, which I have managed to set up properly.
- You must be logged in to reply to this topic.
