Patching Pixel 10 kernel to allow more resolutions in desktop mode

azaydan

Hi, I use my pixel plugged in as a thin client for programming. On both stock and GrapheneOS the phone never shows ultrawide resolutions (21:9 or 32:9) with the two ultrawide monitors that I have. I was curious as to why that might be the case, so I went digging into the kernel code and found the following whitelist in the code :

static struct dptx_allowed_mode dptx_allowed_modes[] = {
	{3840, 2160, 594000},  /* CEA-861 */
	{3840, 2160, 533250},  /* CVT-RB */
	{3840, 1600, 395000},  /* CVT-RB */
	{3440, 1440, 319750},  /* CVT-RB */
	{2560, 1600, 348500},  /* DMT 0x4D */
	{2560, 1440, 241500},  /* CVT-RB */
	{2560, 1080, 198000},  /* CEA-861 */
	{1920, 1200, 193250},  /* DMT 0x45 */
	{1920, 1080, 148500},  /* DMT 0x52 | CEA-861 */
	{1600,  900, 108000},  /* DMT 0x53 */
	{1280,  720,  74250},  /* DMT 0x55 | CEA-861 */
	{1024,  768,  65000},  /* DMT 0x10 */
	{ 800,  600,  40000},  /* DMT 0x9 */
	{ 640,  480,  25175},  /* DMT 0x4 */
};

I decided to build a kernel and ROM with this allowlist simply removed, relying only on the other checks in the file. I succeeded in building but while the new (correct) resolutions showed up on the phone, driving the display no longer worked at all (black output) even with stock-working resolutions. I also confirmed that my build procedure is correct by building the ROM without my patch and flashing to confirm that it did in fact behave just like stock and the GrapheneOS release for my phone. Indeed, without my patch my build only shows the resolutions in the above allowlist and drives the display fine.

I was wondering if anyone would have any idea as to why removing this check breaks display for previously functioning resolutions too, and maybe ideas on what patch would actually work.

TYIA

de0u

azaydan I decided to build a kernel and ROM with this allowlist simply removed, relying only on the other checks in the file.

This description of the patch is informal (an actual patch would be more informative).

Glancing quickly at the code, the struct-array matching loop returns MODE_OK when there is a match. If the loop were just deleted, then it looks as if the function would return MODE_BAD instead.

More generally, it is possible that in standard operation some piece of high-level code tries to set different modes until one works, and the point of this piece of code is to guide that higher-level piece of code away from modes that might work in theory but won't work in practice. If that's the case, then deleting the filtering of non-workable modes would let the high-level code pick a non-workable mode.

At a higher level, somebody put that code there for some reason. It might make sense to look at the commit history to see if there is an explanation.

azaydan

de0u thank you for the response!

This description of the patch is informal

here is the actual patch

it looks as if the function would return MODE_BAD instead

Indeed, I should have been precise in specifying that I changed it to return MODE_OK always.

More generally, it is possible that in standard operation some piece of high-level code tries to set different modes until one works, and the point of this piece of code is to guide that higher-level piece of code away from modes that might work in theory but won't work in practice

You are probably right! I looked into how the allowlist is actually enforced, there is an explicit rates table. I tried the obvious next step, a patch adding to the dptx allowlist and to the DT rates table. Built, flashed, no display. Phone also began to lag heavily with display connected at any selected resolution. I think I am fairly close to giving up as I clearly have no idea what I am doing and I'm on my 10th 6 hour build, sort of spooked about damaging my hardware too 😅

de0u

azaydan It looks to me as if the developer(s) of that code were working from an understanding of what the display hardware can provide, perhaps mediated by beliefs about which monitors are generally available. Any time there is a disagreement between what the software wants and what the hardware can do, the hardware will win, so it's probably useful to find out what the hardware can do.

In terms of potentially-productive steps, I can't help noticing that the dptx_allowed_modes array entries have comments next to them. Decrypting those comments might be productive.