4k Resolution Support - Githubissues

gregordinary commented 4 years ago

According to its datasheet (PDF), the RK3288 should support screen resolutions up to 3840 x 2160. I did a small amount of testing in the Panfrost thread, but ultimately could not get 4k to show up or work on PrawnOS.

My current xrandr output on the latest PrawnOS release shows 1080p as the highest supported resolution on my external monitor:

$ xrandr -q
Screen 0: minimum 320 x 200, current 3286 x 1080, maximum 4096 x 4096
eDP-1 connected 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1366x768      58.30*+
HDMI-1 connected 1920x1080+1366+0 (normal left inverted right x axis y axis) 600mm x 340mm
   1920x1080     60.00*   60.00    30.00    24.00  
   1920x1080i    60.00  
   1600x900      60.00  
   1280x1024     60.02  
   1280x720      60.00  
   1024x768      60.00  
   800x600       60.32  
   720x480       59.94

Over the last month, there's been a thread on the Armbian repo and it looks like with some patches, they have 4k (30hz) working over HDMI 1.4 (2.0 isn't showing 4k). It was tested on the Asus Tinkerboard (RK3288-based).

The c201 should support the same 4k output (ChromeOS did before I wiped it). Hopefully the patches on that Armbian thread are of help.

While my current skill level may not be of much help in the way of creating patches, I'm happy to test out builds and provide output readings if needed.

gregordinary commented 4 years ago

Winged it and tried the patches from the Armbian thread and the display settings now show options for 3840x2160 and 2560x1440.

1440p works but I cannot get 4k to work correctly, presumably because I'm on HDMI 2.0 and don't have a way to force HDMI 1.4, which is what got 4k@30hz working in the Armbian thread.

1440p has a bit of screen tearing with and without panfrost when moving windows around. Perhaps better with wayland.

Screenshot of both screens: https://i.imgur.com/wKV8fsJ.png

Screenshot of available resolutions: https://i.imgur.com/2TvXorL.png

Output of xrandr -q:

Screen 0: minimum 320 x 200, current 3926 x 1440, maximum 4096 x 4096
eDP-1 connected primary 1366x768+0+672 (normal left inverted right x axis y axis) 0mm x 0mm
   1366x768      58.30*+
HDMI-1 connected 2560x1440+1366+0 (normal left inverted right x axis y axis) 600mm x 340mm
   3840x2160     60.00 +  50.00    59.94    30.00    30.00    25.00    24.00    29.97    23.98  
   2560x1440     59.95* 
   1920x1080     60.00    60.00    59.94    30.00    24.00    29.97    23.98  
   1920x1080i    60.00    59.94  
   1600x900      60.00  
   1280x1024     60.02  
   1280x800      59.91  
   1152x864      59.97  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94

Again this is winging it from patches in the Armbian thread but it looks promising.

SolidHal commented 4 years ago

This is awesome! I'll look into including those patches. How does one force HDMI 1.4?

ghost commented 4 years ago

This is awesome! I'll look into including those patches. How does one force HDMI 1.4?

from the armbian thread i would guess he uses a dual-link dvi to hdmi adapter.

gregordinary commented 4 years ago

Yeah, seems to be some type of adapter. Was just looking into it and found this downconverter: https://www.amazon.com/dp/B06XC7VLFV/

Though ultimately the rk3288 has HDMI 2.0 and should be able to do 4k@30Hz without an adapter. Sounds like something with the frequency ranges, but I don't quite understand the details on what's blocking it from working without changing HDMI modes.

ghost commented 4 years ago

https://github.com/armbian/build/pull/1887#issuecomment-626241512

So i guess its just a couple of days away from working with 2.0

Edit: Done with the long thread now. The issue is color management. 4k at 60hz will be doable with limited color space 4:2:0, but this is bad for anything but watching TV. I used that on an old 4k TV for coding and terminal red / blue will bleed, etc. - dual 1920x2160 sounds fun though.

gdallasdye commented 4 years ago

Winged it and tried the patches from the Armbian thread and the display settings now show options for 3840x2160 and 2560x1440.

Would you mind providing the ls output of your patches directory. I git cloned the @Miouyouyou repo, and I'm looking at the thread's PR, and I'm still trying to figure out if I need 1 or 4 or 14 of the patch files...

I already got my kernel config set to enable the staging hantro driver, but is it safe to assume those patches are needed for the kconfig to be effective?

Miouyouyou commented 4 years ago

The patches you're looking for are these ones :

I reworked them here, to slightly diminish their numbers (since some patches are just applied on top of each other), but the rework is not tested for the moment : https://github.com/Miouyouyou/build/tree/Rework/patch/kernel/rockchip-dev

gregordinary commented 4 years ago

@gdallasdye When I first attempted, I just applied all the patches as a "Why not just try it?" type approach. Figured if it worked I'd take a deeper dive and isolate which were specifically needed.

Luckily, Miouyouyou has provided the specific list above, along with some updated patches.

@Miouyouyou - Thanks so much for your work on this!

I tried your consolidated patches on a fresh PrawnOS build and the behavior I'm seeing is that it lists all the expected resolutions, but it only works up to 1920x1080 for the external display. All resolutions above that, regardless of refresh rate are showing a blank screen. This was tested over HDMI. I also tested with an HDMI 2.0 -> 1.4 downconverter. Same behavior.

Wasn't sure if the patches weren't completely agnostic and needed some tailoring for the c201, or perhaps it's the differing kernel versions. Looks like you're building against 5.5.19 and PrawnOS is on 5.4.29. Easy enough to test a later kernel w/ PrawnOS.

Miouyouyou commented 4 years ago

@gregordinary You're welcome ! All the work is from @Kwiboo and @czak though.

Does that mean that :

you tried the first patches and it worked, then you tried the reworked patches and it didn't work ?
OR you tried the first ones and they didn't work ?

I have a hidden noisy patch that displays all the resolutions scanned and why they got ignored. If you can try it and provide the dmesg, this might help understand why you're getting these issues :

https://github.com/Miouyouyou/build/blob/checkmodes/patch/kernel/rockchip-dev/4016-Dumping-validated-modes-for-testing-purposes.patch

Also, are we talking about 60Hz screen or over ? (Like 120Hz+ screens)

gregordinary commented 4 years ago

@Miouyouyou - I tried both.

The original patch set worked, through 1440x2160. The 4k resolution got a blank screen, and I didn't have an adapter available at the time to try different HDMI versions.

Screen is 60hz. I tried w/ 60, 59, 30, and 25hz, where available.

I'll retry the updated patches along w/ the noisy patch and send the dmesg over.

Also a thank you to @Kwiboo and @czak !

gregordinary commented 4 years ago

@Miouyouyou - I tried another build, oddly, this time I'm only getting options for resolutions up to 1920x1080 for the external display. Could very likely be something on my side. I'm going to try building again on my main computer, currently running Ubuntu 20.04; that's what I used for previous builds as well. I'll also try building this in a Debian VM / Remote Server just to see if I'm getting oddities due to my build environment. I'll update if I observe any differences.

Otherwise, I've attached the dmesg output below, and as always open to any suggestions. dmesg.txt

gregordinary commented 4 years ago

@Miouyouyou - Successful build with patches this time. Current output of xrandr:

$ xrandr -q
Screen 0: minimum 320 x 200, current 3926 x 1440, maximum 4096 x 4096
eDP-1 connected primary 1366x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1366x768      58.30*+
HDMI-1 connected 2560x1440+1366+0 (normal left inverted right x axis y axis) 608mm x 355mm
   3840x2160     60.00 +  60.00    50.00    59.94    60.00    30.00    25.00    24.00    29.97    23.98  
   2560x1440     59.95* 
   1920x1080    120.00   100.00   119.88    60.00    60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.88  
   1400x1050     59.95  
   1280x1024     75.02    60.02  
   1440x900      59.90  
   1280x960      60.00  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    70.07    60.00  
   832x624       74.55  
   800x600       72.19    75.00    60.32    56.25  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    72.81    66.67    60.00    59.94  
   720x400       70.08

As with the original patches, I can use the displays up through 2560x1440 but 4k60 produces a blank screen and 4k30 produces an odd display with only a portion of the screen used. See: https://i.imgur.com/F0UFQqI.jpg

Same behavior on two different 4k monitors, one LG and one ViewSonic. In any case, patches seem to work to the same level as the original set. Still attaching the dmesg output just in case its of any interest.

dmesg2.txt

Miouyouyou commented 4 years ago

The 4K behaviour seems indeed weird. Does it do the same inside a console ? Or only through X11 ?

This tiled behaviour is the same with all the 4K frequencies below 30Hz ? If you try 1080p at 30Hz, is it working correctly ?

gregordinary commented 4 years ago

Having varied results depending on the monitor. The LG is a 60Hz monitor and the ViewSonic is 120Hz capable.

On the LG, 1920x1080 displays fine with refresh rates of 24, 25, 30, 59.9, and 60.

On the ViewSonic, I observe the following:

1920x1080
    @120    = good
    @60 = good
    @59.9   = good
    @30 = flicker
    @25 = flicker
    @24 = good

I tried with two different adapters. One micro HDMI cable and one standard HDMI cable with a micro HDMI adapter. Behavior was essentially the same on both, but the micro HDMI cable (no adapter) had much worse flickering, thought I'd still consider both highly unusable (only on the ViewSonic).

Not sure if it's relevant, another observation is the tiled area when switching to 3840x2160@30 is the shape of the tiled display seems to be dictated by the previously set resolution. If the last set resolutions was 2560x1440, the display area looks rectangular, more 16:9. If the last set resolution was 1152x864, the tile display area looks 4:3.

For console. The external display doesn't seem to activate. If I boot on a plain PrawnOS image without X, or if I escape out to TTY2 or similar, the external display goes blank. Not sure what to do to get it to work in this scenario.

I know on previous PrawnOS installations, having an external monitor plugged in would typically mirror what was on the laptop screen automatically.

gdallasdye commented 4 years ago

4K@30FPS works fine for me. My 4K TV allows me to set either HDMI 1.4 or 2.0 modes per input. Testing mostly with Gnome and Wayland/Xwayland. I also have an ultrawide monitor running at 2560x1080@60FPS. I took some screenshots and posted them here. Those screenshots were taken with the reworked patchset.

The "Dumping validated modes for testing purposes" patch did break ultrawide output, but not 4K. The ultrawide screenshots were taken before applying the aforemention patch to the reworked patchset (the one with eight patches). I forgot to backup the os image with just the reworked patchset, and it'll take a few hours build (on C201, over wifi, from scratch), before I can test it again without the validated patch.

I did try to watch a web video at 30FPS, and it felt like it was playing at 15 or 25, not sure. Firefox and that website's "stats for nerds" think it's being played at 30FPS with zero frame drops. I searched for an ultrawide video of a game, and set the playback to 480P. I'll try playing a normal aspect ratio video on my 4K tv, at 1080P and 720P resolutions when I get a chance. I do suspect that playback performance and hdmi support are an unrelated but closely tied issue.

Some xrandr -q commands, with notes.

BTW, is there any specific dmesg command you'd like me to run? I should also disclose that testing occured on Mainline kernel 5.4.42. I'll give it try with Linux-gnu, although I expect no regressions there. I'll also try massaging the patches we currently build with, then try building images with 5.6 and later, and see what breaks where and why. If there's anything to report on that issue, I'll let y'all know.

Miouyouyou commented 4 years ago

Not sure if it's relevant, another observation is the tiled area when switching to 3840x2160@30 is the shape of the tiled display seems to be dictated by the previously set resolution. If the last set resolutions was 2560x1440, the display area looks rectangular, more 16:9. If the last set resolution was 1152x864, the tile display area looks 4:3.

Interesting bug... Does the tile seems to be roughly the same size ? I mean, the ratio is changing, but does switching to 4K@30Hz after a resolution of 1152x864 leads to a 1152x864 tile or something wider ?

For console. The external display doesn't seem to activate. If I boot on a plain PrawnOS image without X, or if I escape out to TTY2 or similar, the external display goes blank. Not sure what to do to get it to work in this scenario.

Maybe it's trying to get to 4K@60Hz and fails. I don't how to force the DRM driver resolution of a specific screen. I guess I should try to modify some DRM-KMS OpenGL example, to use it with a forced resolution.

The "Dumping validated modes for testing purposes" patch did break ultrawide output, but not 4K.

Ow... Maybe there's some timings to respect while detecting resolutions ? Since the patch only add some printk and other resolutions were detected successfully.

I have tested these patches with kernels up to 5.7-rc2 and, so long, they compile. 5.7 kernels add support for YUV 4:2:0 to the HDMI drivers used by RK3288 boards, so give it a try with these additional patches, and see if you can get a display with 4K@60Hz.

gregordinary commented 3 years ago

Revisiting 4k support. Previously I was able to build with the 8 re-worked patches mentioned above. On the latest build, I'm getting errors.

The following are the errors I see, condensed for quick view. More context linked below:

.....
.....
.....
  CC      net/ipv4/ip_fragment.o
  CC      drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.o
  CC      net/netfilter/nf_conntrack_ecache.o
  CC      lib/percpu_counter.o
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c: In function 'dw_hdmi_rockchip_mode_valid':
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:224:27: error: 'info' redeclared as different kind of symbol
  struct drm_display_info *info = &connector->display_info;
                           ^~~~
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:221:39: note: previous definition of 'info' was here
        const struct drm_display_info *info,
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:224:35: error: 'connector' undeclared (first use in this function); did you mean 'drm_connector'?
  struct drm_display_info *info = &connector->display_info;
                                   ^~~~~~~~~
                                   drm_connector
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:224:35: note: each undeclared identifier is reported only once for each function it appears in
make[6]: *** [scripts/Makefile.build:283: drivers/gpu/drm/rockchip/dw_hdmi-rockchip.o] Error 1
make[6]: *** Waiting for unfinished jobs....
  CC      fs/ecryptfs/dentry.o
.....
.....
.....
  CC      fs/nfs/file.o
make[5]: *** [scripts/Makefile.build:500: drivers/gpu/drm/rockchip] Error 2
make[4]: *** [scripts/Makefile.build:500: drivers/gpu/drm] Error 2
make[3]: *** [scripts/Makefile.build:500: drivers/gpu] Error 2
make[3]: *** Waiting for unfinished jobs....
  CC      fs/hfsplus/bnode.o
.....
.....
  AR      drivers/tty/built-in.a
make[2]: *** [Makefile:1784: drivers] Error 2
make[2]: *** Waiting for unfinished jobs....
  CC      fs/cifs/dir.o
  CC      net/ipv4/fib_semantics.o
.....
.....
.....
  AR      fs/built-in.a
make[2]: Leaving directory '/home/myuser/Development/git/myuser/PrawnOS/build/armhf/linux-5.9.12'
make[1]: *** [/home/myuser/Development/git/myuser/PrawnOS/kernel/makefile:130: /home/myuser/Development/git/myuser/PrawnOS/build/armhf/linux-5.9.12/vmlinux.kpart] Error 2
make[1]: Leaving directory '/home/myuser/Development/git/myuser/PrawnOS'
make: *** [makefile:100: image] Error 2

Appears to be related to the following patch: https://github.com/Miouyouyou/build/blob/Rework/patch/kernel/rockchip-dev/4009-drm-rockchip-dw-hdmi-Fusion-of-two-previous-patches.patch

Target of patch: dw_hdmi-rockchip.c.txt

Expanded output of build process: build_error.txt

Let me know if other output is needed.

Miouyouyou commented 3 years ago

Yeah, the signature of the patched function changed a lot. Still, the patch seems to be applicable, though it will clearly need a rewrite :

The connector is now a member of the hdmi structure passed as a pointer https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L143
However, it's now useless since the display info are already passed as a parameter to the function https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c#L222

That said, the content of the function is still roughly the same as the unpatched one, so it will need to be modified. I'll see what I can generate.

Also, be sure to check LibreElec repositories, since their authors generally provide patches for 4K support on modern kernels (and are generally the ones maintaining them on mainline kernels).

SolidHal / PrawnOS

4k Resolution Support #159