Err, funny thing is that 4096x2160 is offered as an option but the right resolution is 3840x2160.

I'm using an external mouse and it seems like the USB-C is completely saturated as the mouse becomes jerky. I'll work around by having a second USB-C to USB-A adaptor or switch to a bluetooth one.

I played a netflix movie (via Chrome) fine for 10 minutes, then switched to second one and ChromeOS shut down upon starting to play it. I think ChromeOS crashed then shut down because the lid was closed.

Did you mean to attach pictures which didn't get attached?

Oops, thanks!

Deleted: lol_arc_app_launcher.jpg 900 KB

	lol_arc_app_launcher.jpg 900 KB View Download

Deleted: mouse_outside_frame_buffer.jpg 777 KB

	mouse_outside_frame_buffer.jpg 777 KB View Download

Looks very much like https://b.corp.google.com/issues/35647600

Disclaimer: I know nothing about this so this is an uninformed opinion.

I think it's different because there's data sent on the right side: I can move the mouse to all the black area and it is correctly drawn. The crash UI correctly extend the black area fine. It's a bit harder to see because the UI darkens the underlying display but if you look carefully at the first screenshot, you see the GUI cutoff is more on the left. On the second screen shot, you clearly see the mouse farther than the GUI cut off. I can move it to the far right and there is no corruption of the pointer.

So I don't think it's a signaling issue at all, and it doesn't seem to be a limit on "2560"; the ratio seems to stay around 3:2 independent on the resolution I select.

I think it is indeed a different issue. I was able to get 4K working here with a different adapter and different 4K monitor. Is it possible for you to try a different 4K monitor, but keep everything else the same? And perhaps a different adapter, but again, keep everything else the same?

I can't afford to buy another 4K TV just for the fun of it (it's personal hardware) and I don't know neighbors with a 4K TV, and I don't think I can expense one to try it out. 😶

I can get/expense the official USB-C for HDMI on Google Store (or any other you know is working) to weed out if this is purely interference from the Samsung official adaptor. This would help narrow down the scope if it is the TV itself. It's low cost. wdyt?

OK - my hunch is that the problem is with the 4K TV, but it could also be the adapter.  If you want to try a different adapter, this is the one that's working for me:

https://www.uptab.com/usbc-hdmi-2-port-usb3-card-reader-pd-gigabit-ethernet-adapter-graphite.html

If you can switch the chromebook to developer mode and go to the console (ctrl-alt-rightarrow) and capture the output of the modetest command, that would be very helpful.

Interesting, because the adaptor you linked to is HDMI 1.4 (30Hz), not 2.0 (60Hz). I chose the Samsung one because it is listed to support HDMI 2.0. I guess I can still try it but my goal is to go with HDMI 2.0.

I've been able to get 3840x2160 more consistently as I notice when it selects 4096x2160 by error whenever I plug/unplug it. Maybe the 55SJ8500 EDID is incorrect?

I'll try dev mode and will report back a bit later. Thanks!

Tangential issues:
- The crash on netflix is likely an unrelated issue.
- Sadly I've been unable to make http://i.rtings.com/images/test-materials/2017/chroma-444.png appear totally clear as listed on http://www.rtings.com/tv/learn/chroma-subsampling. Sadly I played with oversampling in the display settings and I can't find how to reset the value back, "reinitialize" doesn't do what is expected, it discards current change, doesn't reinitialize to default settings. Looks like a bug.

Ping, Kristian any update?

In my case, I got it to work by carefully selecting 3840x2160 every single time. Any other resolution result in corruption.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6ecde4b9a8f8f66e3b11ef616bde479fdd807741

commit 6ecde4b9a8f8f66e3b11ef616bde479fdd807741
Author: Kristian H. Kristensen <hoegsberg@chromium.org>
Date: Tue Nov 21 02:13:40 2017

CHROMIUM: drm/rockchip: Prune modes wider than 3840

BUG=761104
TEST=Plug in monitor with modes wider than 3840, verify that KMS
  rejects them (modetest -M rockchip | grep -E '[0-9]+x[0-9]+').

Change-Id: I8cc732c57c799ba4c63c16c96682f3bcd5253c91
Reviewed-on: https://chromium-review.googlesource.com/779968
Commit-Ready: Kristian H. Kristensen <hoegsberg@chromium.org>
Tested-by: Kristian H. Kristensen <hoegsberg@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@google.com>

[modify] https://crrev.com/6ecde4b9a8f8f66e3b11ef616bde479fdd807741/drivers/gpu/drm/rockchip/rockchip_drm_fb.c

Did we loop in anyone from Rockchip? They're looking at another problem like this [1] (likely a different problem, but you never know).

[1] https://issuetracker.google.com/69589805

The rk3399 datasheet says max resolution for VOP_BIG is:

Max output resolution：4096x2160

...so, in theory, it should be supported.  ...but yeah, it seems like it could be just a magic bit that needs to be set somewhere.  I could sorta believe we need some magic change like we needed in rk3288 at <https://chromium-review.googlesource.com/287494>.  In rk3288, though, that was needed to get 3840 resolution (the max support on rk3288).

Yes, this isn't the best fix, that's for sure, but the impact of dropping down to 3840 should be minimal.  Apparently there are actual 4096 wide monitors:

   "DCI 4K which has a resolution of 4096 × 2160 pixels (256:135, approximately a 
    1.9:1 aspect ratio). This standard is only used in the film and video 
    production industry."

but for Chromebooks, we're probably more likely to encounter that as a monitor or dongle advertising bad modes (the case here, I believe).

That said, looking at the pictures above again, it does look like perhaps it's a higher level problem.  Maybe chrome only allocates a 2560 wide framebuffer, but KMS correctly sets a 4096 wide mode. RK3399 does support a primary framebuffer that's a different size (eg smaller) than the mode.  The error popup in the app launcer picture in #4 could be an overlay plane from ARC++ that expands beyond the smaller primary framebuffer (we do use overlays for ARC++ windows).

I used to have access to a monitor that advertised 4096 pixels wide.  It was in the old partner lab.  I can see if I can track it down if it's useful to anyone.

Yes, that would be interesting.

@18: OK, I tracked down the monitor at the lab.  It truly has 4096x2160.  I connected Kevin (via Anker dock) and looked at the on-screen info on the TV, the TV thinks is is connected at:

 4096x2160/24p

I saw what was described here originally (right 3rd of the screen is black but I can move my mouse cursor there).  Then I bumped the resolution down to 3840 and back up to 4096x2160/24p and everything worked just fine.

So the display works fine at the higher resolution, we're just not setting it up right.

---

Debug info while connected to this monitor:

modetest=<multiline>
---------- START ----------
trying to open device 'i915'...failed
trying to open device 'amdgpu'...failed
trying to open device 'radeon'...failed
trying to open device 'nouveau'...failed
trying to open device 'vmwgfx'...failed
trying to open device 'omapdrm'...failed
trying to open device 'exynos'...failed
trying to open device 'tilcdc'...failed
trying to open device 'msm'...failed
trying to open device 'sti'...failed
trying to open device 'tegra'...failed
trying to open device 'imx-drm'...failed
trying to open device 'rockchip'...done
Encoders:
id	crtc	type	possible crtcs	possible clones	
35	29	TMDS	0x00000003	0x00000000
37	32	TMDS	0x00000002	0x00000000

Connectors:
id	encoder	status		name		size (mm)	modes	encoders
36	35	connected	eDP-1          	259x173		1	35
  modes:
	name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  2400x1600 60 2400 2448 2480 2564 1600 1603 1613 1733 266667 flags: nhsync, nvsync; type: preferred, driver
  props:
	1 EDID:
		flags: immutable blob
		blobs:

		value:
	2 DPMS:
		flags: enum
		enums: On=0 Standby=1 Suspend=2 Off=3
		value: 0
38	37	connected	DP-1           	890x500		42	37
  modes:
	name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot)
  4096x2160 24 4096 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
  4096x2160 24 4096 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
  3840x2160 30 3840 4016 4104 4400 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
  3840x2160 25 3840 4896 4984 5280 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
  3840x2160 24 3840 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver
  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver
  1920x1080 60 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: phsync, pvsync; type: driver
  1920x1080 50 1920 2448 2492 2640 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver
  1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
  1920x1080 30 1920 2008 2052 2200 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
  1920x1080 25 1920 2448 2492 2640 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver
  1920x1080 24 1920 2558 2602 2750 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver
  1680x1050 60 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: driver
  1600x900 60 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver
  1280x1024 75 1280 1296 1440 1688 1024 1025 1028 1066 135000 flags: phsync, pvsync; type: driver
  1280x1024 60 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver
  1440x900 60 1440 1488 1520 1600 900 903 909 926 88750 flags: phsync, nvsync; type: driver
  1366x768 60 1366 1436 1579 1792 768 771 774 798 85500 flags: phsync, pvsync; type: driver
  1280x800 60 1280 1328 1360 1440 800 803 809 823 71000 flags: phsync, nvsync; type: driver
  1152x864 75 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, pvsync; type: driver
  1280x720 60 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver
  1280x720 60 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync, pvsync; type: driver
  1280x720 50 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync, pvsync; type: driver
  1024x768 75 1024 1040 1136 1312 768 769 772 800 78800 flags: phsync, pvsync; type: driver
  1024x768 70 1024 1048 1184 1328 768 771 777 806 75000 flags: nhsync, nvsync; type: driver
  1024x768 60 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; type: driver
  832x624 75 832 864 928 1152 624 625 628 667 57284 flags: nhsync, nvsync; type: driver
  800x600 75 800 816 896 1056 600 601 604 625 49500 flags: phsync, pvsync; type: driver
  800x600 72 800 856 976 1040 600 637 643 666 50000 flags: phsync, pvsync; type: driver
  800x600 60 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; type: driver
  720x576 50 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver
  720x480 60 720 736 798 858 480 489 495 525 27027 flags: nhsync, nvsync; type: driver
  720x480 60 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver
  640x480 75 640 656 720 840 480 481 484 500 31500 flags: nhsync, nvsync; type: driver
  640x480 73 640 664 704 832 480 489 491 520 31500 flags: nhsync, nvsync; type: driver
  640x480 67 640 704 768 864 480 483 486 525 30240 flags: nhsync, nvsync; type: driver
  640x480 60 640 656 752 800 480 490 492 525 25200 flags: nhsync, nvsync; type: driver
  640x480 60 640 656 752 800 480 490 492 525 25175 flags: nhsync, nvsync; type: driver
  720x400 70 720 738 846 900 400 412 414 449 28320 flags: nhsync, pvsync; type: driver
  props:
	1 EDID:
		flags: immutable blob
		blobs:

		value:
			00ffffffffffff004c2db40b01000000
			02180103805932780aee91a3544c9926
			0f5054bdef80714f81c0810081809500
			a9c0b300010108e80030f2705a80b058
			8a00501d7400001e023a801871382d40
			582c4500501d7400001e000000fd0018
			4b0f873c000a202020202020000000fc
			0053414d53554e470a2020202020012c
			02033af15761101f041305142021225d
			5e5f6065666263640716031223090707
			83010000e2000f6e030c001000b83c21
			008001020304e30f01e0011d80d0721c
			1620102c2580501d7400009e662156aa
			51001e30468f3300501d7400001e0000
			00000000000000000000000000000000
			00000000000000000000000000000049
	2 DPMS:
		flags: enum
		enums: On=0 Standby=1 Suspend=2 Off=3
		value: 0
	25 Content Protection:
		flags: enum
		enums: Undesired=0 Desired=1 Enabled=2
		value: 0

CRTCs:
id	fb	pos	size
29	40	(0,0)	(2400x1600)
  2400x1600 60 2400 2448 2480 2564 1600 1603 1613 1733 266667 flags: nhsync, nvsync; type: preferred, driver
  props:
32	70	(0,0)	(4096x2160)
  4096x2160 24 4096 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver
  props:

Planes:
id	crtc	fb	CRTC x,y	x,y	gamma size	possible crtcs
27	29	40	0,0		0,0	0       	0x00000001
  formats: XR24:LINEAR AR24:LINEAR XB24:LINEAR AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR NV12:LINEAR NV16:LINEAR NV24:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 1
	26 rotation:
		flags: bitmask
		values: rotate-0=0x1 reflect-y=0x20
		value: 1
28	0	0	0,0		0,0	0       	0x00000001
  formats: XR24:LINEAR AR24:LINEAR XB24:LINEAR AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 2
30	32	70	0,0		0,0	0       	0x00000002
  formats: XR24:CHROMEOS_ROCKCHIP_AFBC XR24:LINEAR AR24:CHROMEOS_ROCKCHIP_AFBC AR24:LINEAR XB24:CHROMEOS_ROCKCHIP_AFBC XB24:LINEAR AB24:CHROMEOS_ROCKCHIP_AFBC AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR NV12:LINEAR NV16:LINEAR NV24:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 1
	26 rotation:
		flags: bitmask
		values: rotate-0=0x1 reflect-y=0x20
		value: 1
31	0	0	0,0		0,0	0       	0x00000002
  formats: XR24:LINEAR AR24:LINEAR XB24:LINEAR AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 2
33	0	0	0,0		0,0	0       	0x00000002
  formats: XR24:LINEAR AR24:LINEAR XB24:LINEAR AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR NV12:LINEAR NV16:LINEAR NV24:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 0
	26 rotation:
		flags: bitmask
		values: rotate-0=0x1 reflect-y=0x20
		value: 1
34	0	0	0,0		0,0	0       	0x00000002
  formats: XR24:LINEAR AR24:LINEAR XB24:LINEAR AB24:LINEAR RG24:LINEAR BG24:LINEAR RG16:LINEAR BG16:LINEAR
  props:
	5 type:
		flags: immutable enum
		enums: Overlay=0 Primary=1 Cursor=2
		value: 0
	26 rotation:
		flags: bitmask
		values: rotate-0=0x1 reflect-y=0x20
		value: 1

Frame buffers:
id	size	pitch

Wow thanks Doug!

The TVs I have seen which support 4096x2160 are really 3840x2160 natively. To expose the 4096x2160 mode, they either downscale to 3840x2160 (which looks ugly/blurry) or overscan (in other words, cut the border to hide the extra 256 pixels). Both these solutions aren't great.

Overall I am not sure we even want the 4096x2160 mode as it's likely to do things that users don't like.

Mine is definitely 3840x2160 and incorrectly advertising.

I didn't count pixels, but that's probably the case here too.  Ironically we probably would have defaulted to 3840x2160 if we actually supported the 594 pixel clock (I guess we don't???)

Decoding the edid:


First detailed timing is preferred timing
...
Detailed mode: Clock 594.000 MHz, 1872 mm x 1053 mm
               3840 4016 4104 4400 hborder 0
               2160 2168 2178 2250 vborder 0
               +hsync +vsync 

If 3840 is the preferred mode then that's probably the real native resolution.


It still seems like we have a real bug somewhere, but I guess we could paper over it given that most people won't really have monitors that support 4096...

That's weird, the EDID doesn't have a 4096 wide mode in it, but KMS reports one? Additionally, the modetest output doesn't list a preferred mode... smells fishy.

There are definitely some 4096x2160 modes in the standard modes:

Extracted contents:
header:          00 ff ff ff ff ff ff 00
serial number:   4c 2d b4 0b 01 00 00 00 02 18
version:         01 03
basic params:    80 59 32 78 0a
chroma info:     ee 91 a3 54 4c 99 26 0f 50 54
established:     bd ef 80
standard:        71 4f 81 c0 81 00 81 80 95 00 a9 c0 b3 00 01 01
descriptor 1:    08 e8 00 30 f2 70 5a 80 b0 58 8a 00 50 1d 74 00 00 1e
descriptor 2:    02 3a 80 18 71 38 2d 40 58 2c 45 00 50 1d 74 00 00 1e
descriptor 3:    00 00 00 fd 00 18 4b 0f 87 3c 00 0a 20 20 20 20 20 20
descriptor 4:    00 00 00 fc 00 53 41 4d 53 55 4e 47 0a 20 20 20 20 20
extensions:      01
checksum:        2c

Manufacturer: SAM Model bb4 Serial Number 1
Made week 2 of 2014
EDID version: 1.3
Digital display
Maximum image size: 89 cm x 50 cm
Gamma: 2.20
Supported color formats: RGB 4:4:4, YCrCb 4:4:4
First detailed timing is preferred timing
Established timings supported:
  720x400@70Hz
  640x480@60Hz
  640x480@67Hz
  640x480@72Hz
  640x480@75Hz
  800x600@60Hz
  800x600@72Hz
  800x600@75Hz
  832x624@75Hz
  1024x768@60Hz
  1024x768@70Hz
  1024x768@75Hz
  1280x1024@75Hz
  1152x870@75Hz
Standard timings supported:
  1152x864@75Hz
  1280x720@60Hz
  1280x800@60Hz
  1280x1024@60Hz
  1440x900@60Hz
  1600x900@60Hz
  1680x1050@60Hz
Detailed mode: Clock 594.000 MHz, 1872 mm x 1053 mm
               3840 4016 4104 4400 hborder 0
               2160 2168 2178 2250 vborder 0
               +hsync +vsync 
Detailed mode: Clock 148.500 MHz, 1872 mm x 1053 mm
               1920 2008 2052 2200 hborder 0
               1080 1084 1089 1125 vborder 0
               +hsync +vsync 
Monitor ranges (GTF): 24-75Hz V, 15-135kHz H, max dotclock 600MHz
Monitor name: SAMSUNG
Has 1 extension blocks
Checksum: 0x2c (valid)

CEA extension block
Extension version: 3
54 bytes of CEA data
  Video data block
    VIC  97 3840x2160@60Hz 
    VIC  16 1920x1080@60Hz 
    VIC  31 1920x1080@50Hz 
    VIC   4 1280x720@60Hz 
    VIC  19 1280x720@50Hz 
    VIC   5 1920x1080i@60Hz 
    VIC  20 1920x1080i@50Hz 
    VIC  32 1920x1080@24Hz 
    VIC  33 1920x1080@25Hz 
    VIC  34 1920x1080@30Hz 
    VIC  93 3840x2160@24Hz 
    VIC  94 3840x2160@25Hz 
    VIC  95 3840x2160@30Hz 
    VIC  96 3840x2160@50Hz 
    VIC 101 4096x2160@50Hz 
    VIC 102 4096x2160@60Hz 
    VIC  98 4096x2160@24Hz 
    VIC  99 4096x2160@25Hz 
    VIC 100 4096x2160@30Hz 
    VIC   7 1440x480i@60Hz 
    VIC  22 1440x576i@50Hz 
    VIC   3 720x480@60Hz 
    VIC  18 720x576@50Hz 
  Audio data block
    Linear PCM, max channels 2
    Supported sample rates (kHz): 48 44.1 32
    Supported sample sizes (bits): 24 20 16
  Speaker allocation data block
    Speaker map: FL/FR
  Extended tag: video capability data block
    YCbCr quantization: No Data (0)
    RGB quantization: No Data (0)
    PT scan behaviour: No Data (0)
    IT scan behaviour: Support both over- and underscan (3)
    CE scan behaviour: Support both over- and underscan (3)
  Vendor-specific data block, OUI 000c03 (HDMI)
    Source physical address 1.0.0.0
    Supports_AI
    DC_36bit
    DC_30bit
    DC_Y444
    Maximum TMDS clock: 300MHz
    Extended HDMI video details:
      HDMI VIC 0 3840x2160@30Hz
      HDMI VIC 1 3840x2160@25Hz
      HDMI VIC 2 3840x2160@24Hz
      HDMI VIC 3 4096x2160@24Hz
  Extended tag: YCbCr 4:2:0 capability map data block
Underscans PC formats by default
Basic audio support
Supports YCbCr 4:4:4
Supports YCbCr 4:2:2
1 native detailed modes
Detailed mode: Clock 74.250 MHz, 1872 mm x 1053 mm
               1920 2448 2492 2640 hborder 0
                540  542  547  562 vborder 0
               +hsync +vsync interlaced 
Detailed mode: Clock 85.500 MHz, 1872 mm x 1053 mm
               1366 1436 1579 1792 hborder 0
                768  771  774  798 vborder 0
               +hsync +vsync 
Checksum: 0x49 (valid)

I see, ok... but it still looks like KMS loses the "First detailed timing is preferred timing" information somewhere.

Yeah, I likely have an old version of the edid decoder.  I'll have to update it.

Presumably something in our software is rejecting the 594 MHz Pixel clock.  I'm not sure if that's simply not supported on our hardware or if it's a bug.

It does seem like perhaps something in the software could choose the same resolution but lower refresh rate if the default mode isn't there.  Right now I'd guess that it just filters out the default mode and then behaves as if there isn't a default mode...

Yes, there are no pixel clocks > 297MHz in the modetest output, so it's likely that those got filtered out.