Display limited to 800x600 [SOLVED]

[Averell]

Hello,
I used the Pine64 installer to install a "Community Debian Stretch Mate". Indicated version, in July 2018 is : 0.5.15
Beautiful installer, everything fine but the display : it is locked to 800x600, and somewhere a message indicates that the display card is not recognised. I thought I would find a solution and set up the Linux, and used it for some time. But nothing was found to fix the display problem.
Further tests showed that only the 0.6.x versions give me the normal resolution of the display (1280 x 1024 DVI). I tried with :

• Community Debian Stretch Mate (0.5 : Bad)
  
• Community Debian Stretch Minimal (0.6 : OK)
  
• Community Bionic Lxde (0.6 : OK)
  
• Community Xenial Mate (0.5 : Bad)
  

I found later that Ayufan builds really work from 0.6 versions. It is regretful that the 0.5 versions are not yet replaced in the Pine64 installer.

A good desktop experience

Question : is it possible to fix the problem in the installed 0.5 version, or is it necessary to start all over from scratch ?

A strange phenomenon : The defective Debian runs on the eMMC. I tried to flash a SD card with a Bionic 0.6 version. Tested on a second Rock64 : fine. I put the SD card in the first Rock64 : The Bionic is launched, but the display is 800x600. At first, I thought the Rock64 was defective. Then I tried to remove the eMMC card : then the Bionic starts with the 1280,1024 resolution. What can be the reason ? Are some files read first on the eMMC card, when a SD card is present ?

Thanks if someone has a suggestion. I would hate to reinstall everything.
But what I really like with this little thing is the perfect silence.

[ab1jx]

I think the problem is at a lower level than Linux, maybe something in the GPU firmware.  I'm having trouble with:
Linux version 4.4.126-rockchip-ayufan-239 (root@b57dd544ff03) (gcc version 7.2.0 (Ubuntu/Linaro 7.2.0-6ubuntu1) ) #1 SMP Sun May 27 18:38:24 UTC 2018

I'm trying to run on a 13 inch Axess TV that has a physical resolution of 1366x768.  It's running in 1920x1080 mode, both by the monitor and xrandr.  I can sort of read it with a magnifying glass but the menu, system tray, etc. are off screen in LXDE.  It affects both text mode and X so it's not just X(org).  I was playing with it last night and I could make some changes at least using xrandr, too soon to know if any of them are useful.  I doubt it.

Last night I tried xorg -configure and it didn't see the monitor at all.  This is about 5 years old, has an EDID that doesn't work with a Raspberry Pi either.  But on those you can manually choose a video mode by setting an HDMI or CVT mode in your /boot/config.txt.  We don't have that on the Rock and Pine, yet anyway.

I've pretty sure the way it works is that the GPU sets up a frame buffer somewhere in Mali land then the console and X write into it.  But the GPU is in control of the output size, I'm not sure what we can do to talk to it.  fbset says:

Code:

mode "1920x1080"
   geometry 1920 1080 1920 1080 32
   timings 0 0 0 0 0 0 0
   accel true
   rgba 8/16,8/8,8/0,0/0
endmode

Acceleration is working, I get 180 and 150 fps from glxgears and es2gears.  Can't read it but it's fast.

When I try to set 1024x768-60 mode with fbset I get "FBIOPUT_VSCREENINFO: Invalid argument".  Looks like that's from an ioctl.  But fbset is ancient by arm standards, I'm not surprised it doesn't work.

[Averell]

Hello,

Question : is it possible to fix the problem in the installed 0.5 version, or is it necessary to start all over from scratch ?

We have found a workaround :

1. Install a Community Debian Stretch Minimal, build 0.6.44 on a Micro SD card.
   
2. Verify it works correctly, and for this remove first the eMMC, and run on the SD card alone. The display resolution should be OK with a 0.6.x build.
   
3. Remove the SD card, install it in a card reader
   
4. Restart the Rock 64
   
5. mount the partition of the SD card where you can find the right files, for us it was sda6, corresponding to the mmcblk0p6 partition.
   
6. Replace all the files of /boot/efi of the Rock64 by the corresponding files found on the SD card :
   

• extlinux/extlinux.conf
  
• dtb
  
• image
  
• initrd.img
  

After a restart, the display is OK

[ab1jx]

Seems a bit sledgehammerish (doesn't that replace the kernel too?) but maybe it will get Ayufan's attention to the fact there's a problem.  My guess is this only happens with monitors 5 years or so old and more because the EDID is a different version.  The USB keyboard thing still needs the manual printk fix too.

My workaround is less drastic and less permanent.  Find an randr client that works in your case, I used lxrandr.  Set the screen size to something that should fit, like 1024x768.  That works for me, at least for X, but it reverts to 1920x1080 on reboot.  I think it only changes something in X and the change doesn't get written to the Mali.  I tried fbset, xvidtune, xset, none will do.  Probably a modeline would be a waste of time.  It wouldn't surprise me if there's some utility that controls the Mali but I haven't found it yet.  Maybe it can only be set at boot.  I have an adapter to get a serial console (https://www.adafruit.com/product/954) on order, a guy I was chatting with at Armbian says all the important stuff is done through serial.  The errors I get seem like the Mali refuses to listen to X.  I think there's a lot of documentation we don't have, maybe it's all in Chinese.

This is close, but more about features rather than controlling it.  https://developer.arm.com/docs/dui0505/l...troduction Maybe the interference with control comes from Xorg itself as some sort of security measure.  I'm not the client so I can't set certain things. But no, the problem is the console size too.  Resizing the framebuffer seems like what needs to be done.  Maybe the size can only be set at boot.

I'm looking at a 1024x768 screen I set with lxrandr, it looks right, my monitor says it's 1024x768.  But fbset or fbset -i says it's 1920x1080.  ls /dev/fb* finds only fb0, and lsof | grep  "/dev/fb" shows nothing has it open.  They're 2 different things.  What does lxrandr connect to?  I thought it was just an interface to randr.  But I rebooted, my console is 1920x1080, brought up X and it's 1024x768.  They're 2 different things.

Posted question at https://unix.stackexchange.com/q/454406/192145

[Averell]

I will try to refine the workaround, and see which file is responsible, but the best option for anyone is to be prudent and download a 0.6.x build.
The monitor is a Iiyama B1906S, 1280x1024 (4:5), probably more than 5 years old.

[ab1jx]

I will try to refine the workaround, and see which file is responsible, but the best option for anyone is to be prudent and download a 0.6.x build.
The monitor is a Iiyama B1906S, 1280x1024 (4:5), probably more than 5 years old.

I think only 1 of my 3 or so monitors works (automatically/EDID), that's a Dell SE2216 I bought within the last year.  $100 at Walmart, 22 inch.  It's not a problem to set a mode manually if you know how.  For a Raspberry Pi it's doumented.

Anyway I stumbled across this post https://unix.stackexchange.com/questions...y-set?rq=1 which led me to start looking in /sys/devices/platform/display-subsystem/drm/card0/device/graphics/fb0


There's a bunch of stuff in there I never found before.  It may be a virtual filesystem like /proc.  There's a file called mode which had 1920,1080 in it (I think).  I tried echo 1366,768 > mode and X stopped.  So it's active.  Now it seems to be empty, wonder what a reboot will do.  There's a modes file which has "U:1920x1080p-0" in it.  virtual_size which now at least says 1366,768.   A bunch of maybe-related stuff is symlinked from directories off /sys/class.  There were 2 places, it's like a maze.  In here I see:

Code:

-rw-r--r-- 1 root root 4096 Jul 11 03:52 bits_per_pixel
-rw-r--r-- 1 root root 4096 Jul 11 03:52 blank
-rw-r--r-- 1 root root 4096 Jul 11 03:52 console
-rw-r--r-- 1 root root 4096 Jul 11 03:52 cursor
-r--r--r-- 1 root root 4096 Jul 11 03:52 dev
lrwxrwxrwx 1 root root    0 Jul 11 03:52 device -> ../../../display-subsystem
-rw-r--r-- 1 root root 4096 Jul 11 03:41 mode
-rw-r--r-- 1 root root 4096 Jul 11 03:52 modes
-r--r--r-- 1 root root 4096 Jul 11 03:52 name
-rw-r--r-- 1 root root 4096 Jul 11 03:52 pan
drwxr-xr-x 2 root root    0 Jul 11 03:52 power
-rw-r--r-- 1 root root 4096 Jul 11 03:52 rotate
-rw-r--r-- 1 root root 4096 Jul 11 03:52 state
-r--r--r-- 1 root root 4096 Jul 11 03:52 stride
lrwxrwxrwx 1 root root    0 Jul 11 03:52 subsystem -> ../../../../../class/graphics
-rw-r--r-- 1 root root 4096 Jul 11 03:52 uevent
-rw-r--r-- 1 root root 4096 Jul 11 03:53 virtual_size
rock64# 

A Raspberry Pi has simlar stuff in /sys/class/graphics, even my Android phone does.

Now I can't write into mode, that may be a PAM/Selinux/Apparmor thing.  I was doing cat to read and echo > to change, I didn't try opening one in an editor.  Seems like I'm still not really getting anywhere.

[ab1jx]

I just got this in /var/log/messages when I did startx and lxrandr kicked it into 1024x768:

Jul 11 05:33:09 rock64 kernel: [ 140.735158] rockchip-vop ff370000.vop: [drm:vop_crtc_enable] Update mode to 1024x768p0, type: 11

So I just wasn't Googling the right stuff. rockchip-vop turned up this: https://www.mjmwired.net/kernel/Document...ip-vop.txt
But, it's coming up on 2 AM, this can wait until tomorrow.

[ab1jx]

I just did an fbset with a -g and geometery specs. Ran fbset again to check what I'd set, that was fine. But the screen did something else entirely. Like I'd been manipulating a different framebuffer, but I only see one.

Or PAM/Selinux/Aparmor has been told to not let the user change the framebuffer size, assuming the EDID parser works perfectly so there's no reason to give the user access. I hate that big brother crap. And it's sneaky, I've wasted days trying to do things I was just being prevented from doing with no error messages. But you have to study it to dismantle it and I haven't had the stomach for that yet.

I'll get back to it in a few hours.

[ab1jx]

This is maybe the most promising thing I've found: https://linux-sunxi.org/Display  The default video mode can be fed to uboot in a string like

Code:

# fixed mode
setenv bootargs console=tty0 hdmi.audio=EDID:0 disp.screen0_output_mode=1280x720p60 root=/dev/mmcblk0p1 rootwait panic=10

A bunch of that looks like what's in /boot/cmdline.txt on a Raspberry Pi.  Uboot passes it to the kernel.  I haven't found anything like it on my Rock64.  But in there you can set the video mode, like 1280x720 above.  I know nothing about uboot except what it does, it boots mostly ARM machines and it's open source.  The Raspberry Pi doesn't use it, it uses a bootloader from Broadcom so an open source alternative was needed.   There must be a way to pass a command line to the kernel on a Rock64.

My latest search was https://duckduckgo.com/?q=uboot+hdmi+mode&t=h_&ia=web  There's more stuff than I can absorb quickly.

Just guessing, fbcon here is the console one, fb0 (aka card0?) is the one X uses?  There's only /dev/fb0 though.

Code:

rock64# pwd
/sys/class/graphics
rock64# ls -la
total 0
drwxr-xr-x  2 root root 0 Jul 13 04:20 .
drwxr-xr-x 64 root root 0 Jul 13 04:20 ..
lrwxrwxrwx  1 root root 0 Jul 13 04:20 fb0 -> ../../devices/platform/display-subsystem/graphics/fb0
lrwxrwxrwx  1 root root 0 Jul 13 04:20 fbcon -> ../../devices/virtual/graphics/fbcon
rock64# 

The X framebuffer and console one seem to be the same size on the screen, but the console one seems to stay at 1920x1080 while I can change the X one with lxrandr.  It seems stable at 1024x768.  I've rebooted a few times and it's in the same mode.  OK, so /sys is kernel output stuff: https://superuser.com/questions/794198/d...s-in-linux

[pfeerick]

Have a look at /boot/efi/extlinux/extlinux.conf for kernel boot time arguments. You'll be wanting to add to the 'append' line...