TC8. Xfbdev.tcz causes the error message "failed in waitforX"

[Juanito]

I don't know if it's neccessary or not - worth a try maybe?

Do you see any Xfbdev related errors in dmesg?

[Frank69]

I had already tried Xfbdev together with the boot code vga = "1366x768". I have put this boot code in the exlinux.conf file behind APPEND. This causes TC to start in text mode. In "dmesg | more" I do not get information about Xfbdev.

[Frank69]

I have tried old settings in onboot.lst again but now Xfdev.tcz above graphics-4.8.17-tinycore.tcz. The same problem. What I have not seen is that above "failed in waitforX" is

Code: [Select]

Gma500 0000: 00: 02.0: trying to get bblank count for disabled pipe 0
Gma500 0000: 00: 02.0: trying to get bblank count for disabled pipe 0
Gma500 0000: 00: 02.0: BL bug: 00000000 save 00000000
Failed in waitforX


[Juanito]

I had already tried Xfbdev together with the boot code vga = "1366x768".

I don't believe you can use vga="1366x768", see here:

http://wiki.tinycorelinux.net/wiki:display_modes?s[]=xfbdev

[Frank69]

The correct display mode is not in the list that you get with Xvesa -listmodes.

[Juanito]

I meant, for example, that you'd need to use "vga=792" if you wanted 1024x768x24, rather than "vga=1024x768x24".

I get this:

Code: [Select]

$ Xvesa -listmodes
VBE version 3.0 (Intel(R) HSW Mobile/Desktop Graphics Chipset Accelerated VGA BIOS)
DAC is fixed, controller is VGA compatible, RAMDAC causes snow
Total memory: 32704 kilobytes
0x0013: 320x200x8 (vga compatible) PseudoColor
0x0105: 1024x768x8 PseudoColor
0x0117: 1024x768x16 TrueColor [5:6:5:0]
0x0118: 1024x768x24 TrueColor [8:8:8:8]
0x0112: 640x480x24 TrueColor [8:8:8:8]
0x0114: 800x600x16 TrueColor [5:6:5:0]
0x0115: 800x600x24 TrueColor [8:8:8:8]
0x0101: 640x480x8 PseudoColor
0x0103: 800x600x8 PseudoColor
0x0111: 640x480x16 TrueColor [5:6:5:0]
0x017D: 1366x768x8 PseudoColor
0x017E: 1366x768x16 TrueColor [5:6:5:0]
0x017F: 1366x768x24 TrueColor [8:8:8:8]..I believe that if you don't see 1366x768, then you will not get it with Xvesa or Xfbdev.

[Juanito]

Have you tried modifying the first line of .xsession to use the "-screen" option set to one of the resolutions that does exist in "Xvesa -listmodes", for example:

Code: [Select]

/usr/local/bin/Xfbdev -screen 1024x768x24 -mouse /dev/input/mice,5 -nolisten tcp -I

[Frank69]

The highest resolution in that list is with me 1024x786x24. If I understand you well, the resolution of my laptop (WXGA 1366 x 768) can not be seen with Xvesa or Xfbdev. However, it is strange that he sometimes TC starts the desktop with the right resolution.

[Juanito]

Did you see the same problems in tc-7.x or did you reliably get 1366x768?

If you are not limited by performance or space constraints, you could try Xorg-7.7:

* without graphics-KERNEL it should use the vesa driver
* with graphics-KERNEL it should use the modesetting driver

Other than that, I believe you're probably stuck without 1366x768 

[Frank69]

I have tested TC7.2 multiple times. It turns out that the same problem also occurs there. With Xorg.tcz, TC switches to the correct resolution but is far too slow. I think Curage is right and that it has to do with the support of the GMA500 chipset in Xvesa. If I have read correctly, Puppy Linux has a custom Xvesa driver for this problem. I have not tried Puppy yet, but can you use that driver with TC?

Juanito, Rich and Curage Thank you for your help!

[Juanito]

The puppy Xvesa would probably work on tinycore - give it a try.

[Juanito]

It took some time to find a usb stick that would boot in legacy-bios mode and then only corepure64, but anyway..

If I boot in legacy-bios mode without a "vga=" code, Xfbdev gives a /dev/fb0 error and will not start.

If I boot in uefi mode without a "vga=" code, Xfbdev starts at the native resolution of 1366x768 (which has been set by grub2)

I tried booting in legacy-bios mode with "vga=792" and got the grey screen with an "X" cursor - on checking, I found .xsession was trying to use Xvesa, even though /etc/sysconfig/Xserver=Xfbdev and Xvesa does not exist on corepure64.

On correcting .xsession to use Xfbdev, startx resulted in a normal desktop at 1024x768

I tried to use "vga=895" (0x017f+0x0200=0x037f=895), but I got an error about this being depreciated.

For reference:

Code: [Select]

$ dmesg | grep fb [legacy-bios vga=792]
...
vesafb: mode is 1024x768x32, linelength=4096, pages=0
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90000400000, using 3072k, total 3072k
fb0: VESA VGA frame buffer device

Code: [Select]

$ dmesg | grep fb [uefi gfxmode=1366x768x32]
...
efifb: probing for efifb
efifb: framebuffer at 0xe0000000, using 4160k, total 4160k
efifb: mode is 1366x768x32, linelength=5504, pages=1
efifb: scrolling: redraw
efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
fb0: EFI VGA frame buffer device

[Frank69]

Hello Juanito,
The problem is solved. I found out that the GMA500 chipset was also used in the eeepc. On the forum I found this topic. It is about adjusting the screen resolution by means of a hack.
I have only installed Xvesa.tcz and 915resolution.tcz. In the file

Code: [Select]

/opt/bootlocal.sh I have added this code.

Code: [Select]

915resolution 52 1366 768 32
915resolution 54 1366 768 32
After a reboot, the laptop switched to the correct resolution.
thanks again.

[Juanito]

'good to hear you fixed it 

Based on what I see with my hardware, I think you'll be better off with Xvesa.

Dragging a window and scrolling seems to move in slow motion with Xfbdev, whereas it's much better with Xvesa.

BTW, I finally figured out how to get 1366x768 with Xfbdev and a legacy-bios boot with grub2:

Code: [Select]

loadfont unicode
insmod all_video [was previously efi_gop]
set gfxmode=1366x768x32
set gfxpayload=keep
set gfxterm_font=unicode
terminal_output gfxterm

$ dmesg | grep fb
...
vesafb: mode is 1366x768x32, linelength=5504, pages=0
vesafb: scrolling: redraw
vesafb: Truecolor: size=8:8:8:8, shift=24:16:8:0
vesafb: framebuffer at 0xe0000000, mapped to 0xffffc90000800000, using 4160k, total 4160k
fb0: VESA VGA frame buffer device
I guess with some trial and error, I could figure out which specific grub2 video driver is used.

[Frank69]

Thank you for figuring it out. I also did some tests and Xvesa is the fastest. I have to admit that I do not understand how you modified grub2 but I am glad that it has been solved through Xvesa.