Installation doubts

[x18]

Thank you for all that. So did the vesa one hang there? There's no exit code, you know? It almost looks like it's running? If it's not, reduce the depth from 16 to 8--or 4 and take a hack to see if any 1024 stuff runs.

Yes, there are no errors but X doesn't start anyway.

There's a lot to look at, here, given the previous results as well. I still wonder if, in post #54, it was still trying to complete another "RedMaskSize" and the 50 minutes wasn't enough (can you let one thrash overnight?).

No, it stopped after 10-12 minutes. I checked the file date+time. In three attempts it stopped in three different points.
My impression is there is not enough RAM for the system to work.

On TinyCore Linux I've finally got X to work (in a few minutes, not waiting for a long time), but that o.s. is very low RAM demanding.
And the log message is very similar to the above.

And I don't think (guessing only--please correct @Yan) he meant to use any config file but to let it all go with only the default xorg.conf.in as in a fresh installation. Ending day/need to review this with fresh head--thanks again.

You asked me to remove the xorg.conf.in, I used my xorg.conf only.

[grindstone]

Apology for any confusion -- that was just for one test (temporarily removing .conf files). Out of memory "feels right" on the other thing.

[grindstone]

OK, betting TC works because they still build/maintain old XFree86 Xvesa (not Xorg vesa)--even if it uses new kernels. Slitaz has builds both ways (rolling weekly 32-bit seems Xorg, though). Maybe Slitaz is still worth a look for gnumeric etc for you. I'm just hunting tiny X / Xvesa source/status to try to swipe us something.

Bookworm 32-bit pup (<600MB) came out yesterday wont boot here in vbox, but I saw Xorg in the video -- that might work for you and just be usable but...well, it's still Puppy so no joy unless that's an option for you (not an option, here).

------------

Not that you need to care, but as a general FYI to the DSL community, I found TC TinyX source--check out the README on the bottom. Those hardcores seem committed to maintain it (and they link to the pup sources).

https://github.com/tinycorelinux/tinyx

and there are a couple threads on building it with the autotools:
https://forum.tinycorelinux.net/index.ph...271.0.html

------------

Back to the problem, try decreasing bit depth. Your vbemode list was surprisingly hi-res but also saw some 4's and 8's. Decrease the virtual. Try bare minimums to see if the xorg vesa will work At All.

Alternatively, if you've just had it and want help from the real professionals, the X support list is here. You might be able to just paste previous work if you can match up what you did with the logs that came out.

Otherwise, keep us posted on what you're trying. Maybe someone else has ideas. It's not like X hasn't been continually rewritten for 40 years or anything...oh wait

[x18]

Yes, TC works on my laptop either using Xvesa and Xorg, although the latter at 800x600 only.

Unfortunately I can't add more RAM, 160 Mb is the maximum my mainboard supports. That's why I was looking for a lightweight distro. TC and DSL are the less RAM demanding.

I doubt the vbe output is correct since Asus sold this laptop model as a 1024x768 resolution screen. That's I'm currently using with Win 2000.

I've already added subsections with low depth:

Code:

Section "Screen"
    Identifier "Screen0"
    Device     "Videocard0"
    Monitor    "Monitor0"
    DefaultDepth     16
    SubSection "Display"
        Viewport   0 0
        Depth     8
        Modes    "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     16
        Modes    "1024x768" "800x600" "640x480"
    EndSubSection
    SubSection "Display"
        Viewport   0 0
        Depth     24
        Modes    "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

but no way.

[grindstone]

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.

[x18]

My swap is, as used to be in the past century, 2.5 times the RAM: 400Mb.

I think the main point is there is not jet a KMS module for siliconmotion chips, while modesetting requires it to work.
So there is a lack between the siliconmotion driver and (the modern) Xorg.

Ok, I'll contact them. Thank to all of you for your time.