06-04-2024, 03:30 PM
The vbeinfo is what's reported to grub and it's useful for the grub menu, but it's not what gets passed to the kernel. I asked for it to see what grub thinks the bios is reporting to it as possible modes. Discriminating among faulty video card reporting or faulty bios reporting or flaky grub vbeinfo is well beyond me.
Pretty sure some puppy will boot in about the same RAM as we use. If you have a big swap partition (or even a swap file), RAM wont be the limitation, just time for the operations.
free -m
will verify that it's on. In all the hours I've spent messing in DSL, the only times RAM exceeds what you have are when I'm running Firefox or when trying to run 3 other things at once. Your RAM should be fine for a *lot* of daily use cases if we can just get the video straight.
Of course the objective has always been to get the proper siliconmotion driver to run -- that's where the X people can help, but when we're struggling with basic vesa and framebuffer stuff, something isn't right. So much code has changed for so long that I think your work and reporting is important for the X people to know about their vesa server let alone the SMI. A good checksum is a prerequisite.
If the machine was here, there's still a dozen things I'd try, but they are all flock-shooting. If you want the shortest path, let X autoconfig from zero and post those logs to the X people and do what they say. The single best thing you can do is to provide both the input and the output for each test.
Pretty sure some puppy will boot in about the same RAM as we use. If you have a big swap partition (or even a swap file), RAM wont be the limitation, just time for the operations.
free -m
will verify that it's on. In all the hours I've spent messing in DSL, the only times RAM exceeds what you have are when I'm running Firefox or when trying to run 3 other things at once. Your RAM should be fine for a *lot* of daily use cases if we can just get the video straight.
Of course the objective has always been to get the proper siliconmotion driver to run -- that's where the X people can help, but when we're struggling with basic vesa and framebuffer stuff, something isn't right. So much code has changed for so long that I think your work and reporting is important for the X people to know about their vesa server let alone the SMI. A good checksum is a prerequisite.
If the machine was here, there's still a dozen things I'd try, but they are all flock-shooting. If you want the shortest path, let X autoconfig from zero and post those logs to the X people and do what they say. The single best thing you can do is to provide both the input and the output for each test.