Tiny Core Linux
Tiny Core Extensions => TCE Bugs => Topic started by: Frank69 on May 12, 2017, 04:38:45 AM
-
Hello,
I have a fresh TC8.0 installation. As a video driver I have installed graphics-4.8.17-tinycore.tcz and Xfbdev.tcz. I deleted Xvesa from "onboot.lst". When I start TC8.0, the display switches to a high resolution in text mode. Continuing with the error message "failed in waitingforX". Occasionally, TC8 continues and launches the desktop. White the command startx, you get the same message or starts X. Under TC7.2, everything works smoothly. Does anyone have any idea how to solve this?
-
Try this command:
$ cat ~/.xsession
..which should give a first line starting with Xfbdev.
Enter the complete first line at the command prompt and press enter - you should get an error message that gives an indication of the problem.
-
When I enter the "cat ~ / .xsession" command, I see on the first line
/usr/local/bin/Xfbdev -mouse /dev/input/mice,5 -nolisten tcp -I >/dev/null 2>&1 & If you run this after the command prompt, X starts with a gray screen and a cursor (cross). The cursor can be moved.
-
It looks like you have not loaded one or more of the flwm, aterm, wbar, Xlibs and Xprogs extensions?
BTW, I was in error earlier, you would need to enter the first line without ">/dev/null 2>&1" in order to see any error messages.
-
After a new installation on my laptop, I get a boot prompt.
I have downloaded and installed the Xvesa.tcz Xlibs.tcz Xprogs.tcz aterm.tcz flwm_topside.tcz wbar.tcz extensions. Then saved the extension names in onboot.lst. After a reboot I have downloaded Graphics-4.8.17-tinycore.tcz and Xfbdev.tcz. I replaced Xvesa.tcz with graphics-4.8.17-tinycore.tcz and Xfbdev.tcz in onboot.lst. Same result
The command / usr / local / bin / xfbdev -mouse / dev / input / mice, 5 -nolist tcp -I [/ code] returns no error message. X starts with a cursor
-
I just booted tc-8.x x86 with the following and it worked fine:
$ cat /mnt/sdb1/tce/onboot.lst
aterm.tcz
flwm.tcz
wbar.tcz
Xfbdev.tcz
Xprogs.tcz
$ ps aux | grep X
3054 root /usr/local/bin/Xfbdev -mouse /dev/input/mice,5 -nolisten tcp -I
..note that graphics-KERNEL is not loaded
-
This is what I have in onboot.lst (I've temporarily eliminated Graphics-4.8.17 -tinycore.tcz)
Xfbdev.tcz
Xlibs.tcz
Xprogs
aterm.tcz
flwm_topside.tcz
wbar.tcz
nano.tcz
The command ps aux | grep x returns as a result
1432 tc grep x
I wonder. I use a thin client laptop that it is very slow. Could that have anything to do with it?
-
Hi Frank69
Do you really have Xprogs listed without the .tcz extension in your onboot.lst file?
-
My mistake. It is Xprogs.tcz.
I found this forum topic (http://forum.tinycorelinux.net/index.php/topic,20193.msg125680.html#msg125680). Would the speed of my thin client laptop indeed have something to do with my problem? I'm using a Wyse X90cw. According to this site (http://www.parkytowers.me.uk/thin/wyse/x/c/index.shtml) it should work.
-
That laptop has the Intel/PowerVR poulsbo graphics, which are extremely troublesome on all OSes. Does Xvesa not work?
-
Xvesa works but the maximum screen resolution is 1024 x 768. My laptop has a resolution of 1366 x 768. If I try to change the resolution via the Control Panel, it does not appears to work.
-
Using Xvesa, If you exit to a console prompt and use xsetup.sh, does it show 1366 x 768 as an option?
If so, do things work if you choose it and then starttx?
-
If xsetup.sh is used i see a maximum resolution of 1024x786x24. Choose a lower resolution and then startx will change the resolution of the wbar a number of times, after which everything will returns to the original resolution i started with. If i leaves TC with "Exit to Prompt" and then xsetup, I can adjust the resolution but only up to 1024x786.
-
If xsetup.sh does not show 1366x768, I don't think you will get it with Xvesa.
Are you using legacy-bios or uefi boot?
If you are using uefi, it might be possible to set the screen resolution to 1366x768 using grub2 and then use Xfbdev without needing any "vga=" boot code.
-
There is no uefi bios in my laptop. I did not use a VGA boot code. I thought that it was not necessary because it works under TC7.2.
-
I don't know if it's neccessary or not - worth a try maybe?
Do you see any Xfbdev related errors in dmesg?
-
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.
-
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
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
-
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
-
The correct display mode is not in the list that you get with Xvesa -listmodes.
-
I meant, for example, that you'd need to use "vga=792" if you wanted 1024x768x24, rather than "vga=1024x768x24".
I get this: $ 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.
-
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:
/usr/local/bin/Xfbdev -screen 1024x768x24 -mouse /dev/input/mice,5 -nolisten tcp -I
-
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.
-
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 :(
-
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!
-
The puppy Xvesa would probably work on tinycore - give it a try.
-
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: $ 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
$ 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
-
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 (http://forum.tinycorelinux.net/index.php/topic,4361.msg22888.html#msg22888). It is about adjusting the screen resolution by means of a hack.
I have only installed Xvesa.tcz and 915resolution.tcz. In the file
/opt/bootlocal.sh I have added this code.
915resolution 52 1366 768 32
915resolution 54 1366 768 32
After a reboot, the laptop switched to the correct resolution.
thanks again.
-
'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: 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.
-
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.