07:09 <Tim[m]123> Display output on 5.18.5 with rk3399 is broken for me, the right most third of the display output just contains some noise

07:13 <mps> Tim[m]123: this is external display?

07:14 <mps> oh, you are not talking about gru-kevin?

07:37 <Tim[m]123> External display on gru-kevin

07:38 <Tim[m]123> Screen resolution is 3840x1600, output is cut at 2560

07:45 <urja> i bet it picked the big VOP for the internal (because the upstream kernel doesnt care about which is used for what) and is trying to run the external with the small VOP (that is limited to non-4K resolutions)

07:45 <mps> I didn't connected external display for long time, so have no idea does it works correctly with latest kernels

07:47 <mps> and I had smart display which always puts 'screen' in centre

07:49 <Tim[m]123> Hmm, RK3399 has VOP_BIG and VOP_LIT, VOP_LIT supporting only upto 2560x1600, VOP_BIG 4096x2160, so I guess maybe it is using the wrong VOP

07:54 <urja> it's not too hard to test, you can just remove the links between the VOPs and connectors (IIRC... or outputs in some way) you dont wish to be used together in the device tree

07:55 <urja> (the upstream does not want that because it doesnt then anymore totally describe what the hardware can do... -.-)

07:58 <Tim[m]123> But couldn't you check if the resolution is >2560 and then reject or something, I guess the order plays a role too, if one is already used etc.

08:02 <urja> you would actually need to check for resolution <= 2560 and actively choose the little one (but that involves writing code... and i'm not sure how hard it would be to glue that up...)

08:02 <urja> because right now it's just first come first served and the big VOP happens to be the first one in the list to be picked up

08:06 <urja> tbh, i'm surprised that this actually happens (it really tries to run a 4K display, that's wow already) ... also, you'll be disappointed at the performance at the end anyways, it's just too many pixels

08:14 <Tim[m]123> It worked once before and performance wasn't that bad, it runs gnome3 at 60fps with a 4k display, obviously RAM bandwidth is limited and you can't do much 3d stuff

09:25 <Tim[m]123> With VOP_BIG display works at 4k but gnome 42 requires MUTTER_DEBUG_USE_KMS_MODIFIERS=0, so there might still be something wrong

09:28 <Tim[m]123> Without MUTTER_DEBUG_USE_KMS_MODIFIERS=0, console is displayed correctly but as soon as gdm starts, display width is limited again to 2560

10:07 <Tim[m]123> I guess with modifiers it uses AFBC between gpu and vop, maybe that is limited to 2560

10:09 <mps> amstan: ectool works fine to control charging (and not only charging). tested on elm/oak chromebook

10:10 <Tim[m]123> I see there was a patch with "#define ROCKCHIP_MAX_AFBC_WIDTH 2560"

10:10 <mps> but I don't see gru/kevin board in source

10:35 <mps> amstan: also works on gru-kevin

16:46 <hexdump0815> mps: can you please give some details about what you are doing with ectool? is it actually available on linux as well or is it a chromeos thing?

16:51 <mps> hexdump0815: I've built it alpine pkg from chromeos source, APKBUILD file is here https://tpaste.us/4oLw

16:51 <mps> for alpine*

16:53 <mps> hexdump0815: for now I just testing what can be done with it, when I get some grasp I plan to write small daemon to control charging

16:54 <mps> hexdump0815: also I had you and macc24 in mind because of your work for chromebooks, intended to inform you both

16:58 <macc24> yes yes i am busy working on chromebooks

17:01 <mps> macc24: combatant :)

17:25 <hexdump0815> mps: thanks a lot - looks interesting - battery cutoff mode, force lid open mode, wlan/bt radio off (maybe lower level) plus the charging mode adjustemnts

21:01 <mps> hexdump0815: yes, there are interesting things to look for and to use. will take some time to learn about them and see what could be useful in different use cases