05-17-2024, 11:50 PM
You may be right. Hey--I'm no expert, just trying to help and learn this stuff along with everyone else. When I saw the same string
Error, pkgproblemresolver::Resolve generated breaks this may be caused by the ...
elsewhere, it was "...held files" and not "ld files". I just assumed that the ld from yours was not the loader (ld) but a copy-paste error. I understand your point -- feel free to go after ld.
I do not have the answers to those sequencing questions. My sense is that card0 under dri is for accelerated graphics (and your pref to use the proper siliconmotion driver). I am simply trying to exhaust the 2nd option that X was telling us to do--you already reinstalled udev (which should've reconfigured it). Perhaps if we do not autoprobe with X, udev does not fail trying to make a card0 and we communicate with onboard framebuffer vga and not accelerated (DRI) rendering --that's why I said to try to disable the auto. HOWEVER -- now that I go look for the framebuffer device (/dev/fb0), it's not there either:
The thing that's actually working on your box is vesa and that's what sees the 4M of vram. Sooo, vesa doesn't need/use dri. My thinking was to find an X configuration that fit inside 4M and worked with vesa--just to get ANYthing going for you. If we could hatch you a config file with a low-enough pixel-depth to fit inside what's detected, the failures would stop. The problem is that it would not take maximum advantage of your hardware.
It was suggested to try the older 4.19 kernel--perhaps you can try that in the interim. If that "just works", we'll have another set of data. This seems to be in the main antix repository:
linux-4.19.276-antix.2-486-smp
and maybe the headers if you want to build anything again:
linux-headers-4.19.276-antix.2-486-smp
If that kernel gets all the devices populated right...there's the easy answer.
What I know is that you have some sort of display right now and it's using vesa graphics. When I look in the old file from the link in Yan's earlier post, it contains only vesa and fbdev. On your laptop, X already has a configuration, it's just not a runnable one. (Auto-)configuration is to make the process brainless, but if you _know_ what config it will run on, you simply specify that and X will try to use it.
But you are right--the more I read, the more I see these failures all over the place on every possible flavor of distribution--and the solutions are all over the place, too.
Might be interesting to see if
sudo hwinfo --gfxcard
is different from lspci and different from vesa (and / or windows).
Error, pkgproblemresolver::Resolve generated breaks this may be caused by the ...
elsewhere, it was "...held files" and not "ld files". I just assumed that the ld from yours was not the loader (ld) but a copy-paste error. I understand your point -- feel free to go after ld.
I do not have the answers to those sequencing questions. My sense is that card0 under dri is for accelerated graphics (and your pref to use the proper siliconmotion driver). I am simply trying to exhaust the 2nd option that X was telling us to do--you already reinstalled udev (which should've reconfigured it). Perhaps if we do not autoprobe with X, udev does not fail trying to make a card0 and we communicate with onboard framebuffer vga and not accelerated (DRI) rendering --that's why I said to try to disable the auto. HOWEVER -- now that I go look for the framebuffer device (/dev/fb0), it's not there either:
Code:
[ 66.084] (II) Loading sub module "fbdevhw"
[ 66.084] (II) LoadModule: "fbdevhw"
[ 66.085] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 66.091] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 66.091] compiled for 1.21.1.7, module version = 0.0.2
[ 66.091] ABI class: X.Org Video Driver, version 25.2
[ 66.092] (EE) open /dev/fb0: No such file or directoryThe thing that's actually working on your box is vesa and that's what sees the 4M of vram. Sooo, vesa doesn't need/use dri. My thinking was to find an X configuration that fit inside 4M and worked with vesa--just to get ANYthing going for you. If we could hatch you a config file with a low-enough pixel-depth to fit inside what's detected, the failures would stop. The problem is that it would not take maximum advantage of your hardware.
It was suggested to try the older 4.19 kernel--perhaps you can try that in the interim. If that "just works", we'll have another set of data. This seems to be in the main antix repository:
linux-4.19.276-antix.2-486-smp
and maybe the headers if you want to build anything again:
linux-headers-4.19.276-antix.2-486-smp
If that kernel gets all the devices populated right...there's the easy answer.
What I know is that you have some sort of display right now and it's using vesa graphics. When I look in the old file from the link in Yan's earlier post, it contains only vesa and fbdev. On your laptop, X already has a configuration, it's just not a runnable one. (Auto-)configuration is to make the process brainless, but if you _know_ what config it will run on, you simply specify that and X will try to use it.
But you are right--the more I read, the more I see these failures all over the place on every possible flavor of distribution--and the solutions are all over the place, too.
Might be interesting to see if
sudo hwinfo --gfxcard
is different from lspci and different from vesa (and / or windows).