Why can my RPi4 drive my TV right, but my GT 1030 on Windows can't?
April 24, 2021 6:26 PM   Subscribe

So my current PC setup has two computers attached via HDMI to a very old TV - a Toshiba 32AV555D. Windows insists on running this at an "active display resolution" of 1920x1080, despite the 1366x768 panel resolution.

The Raspberry Pi 4 gets a notably better image on the screen, despite the fact that I have to use a workaround to get only almost the right resolution to display (it has to run at 1360x768 because of limitations in the Raspberry Pi hardware).

My main PC is an old Dell with an nVidia GT 1030 in it. It is also connected to the same Toshiba TV via HDMI. However, I cannot find a way to get it to display the native resolution, at least in a way that will stick. It insists on actually sending a 1080p signal, just containing 1366x768 pixels within that, with some blurry scaling. I don't want that.

I want Windows to stop trying to treat this TV like a TV, and treat it like a monitor, using DMT timings. Specifically, I want it to push the native resolution of 1366x768. Most every way I find on the internet to do this doesn't work. The Windows Display Settings dialog will faithfully let me set a 1366x768 or 1360x768 resolution - but the Advanced Display Settings dialog will always show an "active signal resolution" of 1920x1080 alongside a "desktop resolution" of 1366x768.

The nVidia Control Panel is no better - its resolution list is all 1080p or 1080i modes, some with a secondary resolution. It still pushes a 1080 timing signal, then just sends less pixel data within that. Blurry mess. By going into 'customise' I can create a custom resolution, where I can force DMT timings to go with the actual panel resolution of 1366x768. This looks better, but still not as sharp as the Raspberry Pi's output. Windows' advanced display settings shows the desktop resolution and active display resolution matching!

...until I touch anything, launch an app, turn the TV off, etc, etc. Then it's back to sending 1080p blur.

It should absolutely not be the case that the Raspberry Pi can drive a display that much better than a modern-ish graphics card... right?

Help?
posted by Dysk to Computers & Internet (43 answers total)
 
Some TV's have variable quality HDMI ports? Have you tried switching ports / cables?
posted by nickggully at 6:28 PM on April 24, 2021


Response by poster: Yeah, which way round they're plugged in doesn't matter - I can plug the Pi into HDMI1 or HDMI2 with either cable and it displays fine, the Windows PC is blurry AF with any configuration. I'm certain this is a software issue (especially since I can get it to display better than it defaults to, but it takes any excuse to revert to pushing 1080p, which is actually above the native resolution).
posted by Dysk at 6:31 PM on April 24, 2021


Response by poster: (Also in the nVidia control panel 'create custom resolution' dialog, it always defaults to Automatic timings (rather than DMT) where it tries to push 1920x1080. I suspect this is because the TV supports 1080p input modes - it was sold as HDTV capable back in the day - and does internal scaling down to the actual panel res. I don't want that. I just want to push the native panel res directly.)
posted by Dysk at 6:36 PM on April 24, 2021


Response by poster: I'm 99.9% sure this is because the Pi's display settings are forced in /boot/config.txt manually, with absolutely no reading of EDID, and with it forced to effectively send 1360x768 DVI signal down the HDMI cable regardless of what (is anything) is on the other end.

Windows on the other hand, tries to be clever and automagically set something appropriate for the "1080p capable" TV it detects.

It's worth noting that the TV picks this up too - with the Pi, I get "PC Native" and "PC Wide" as aspect ratio setting options, whereas with the Windows PC I get the usual gamut of 4:3, Cinema, Super Wide, etc, etc. The signal the GT 1030 pumps out is a friendly 1080p HDMI signal, to match what the TV (falsely) reports it is. I want Windows to ignore that and just send 1366x768 DVI pixels down that cable, no trying to be clever it respect what's on the other end.

(Oh and as a potential additional wrinkle, I still want to send HDMI audio at the same time. The Pi 4 does this just fine, but I can foresee that being a potential issue with Windows if I find a way to force it to treat the TV as just another monitor.)
posted by Dysk at 6:57 PM on April 24, 2021


By going into 'customise' I can create a custom resolution, where I can force DMT timings to go with the actual panel resolution of 1366x768. This looks better, but still not as sharp as the Raspberry Pi's output.

Have you also tried creating a custom resolution of 1360x768 to try to get an exact match for what the Pi sends? It might well be that the nVidia hardware has a similar timing constraint to the Pi's and is quietly using the next possible timing upward, actually generating 1368x768 whenever 1366x768 is asked for.

The TV would have to resample that for the panel, which would account for the blur. To display 1360x768 it could just letterbox it, which I'm guessing is what "PC Native" means.
posted by flabdablet at 11:44 PM on April 24, 2021


Why can my RPi4 drive my TV right, but my GT 1030 on Windows can't?

The overall answer to this larger question is because your RPi4 is a maximally flexible hobbyist machine with all the controls exposed for you to play with, while both your Windows box and your TV are mass-market consumer-oriented devices built to provide a plug-and-play experience to people who neither know nor care what a pixel is and will simply endure shitty video because it doesn't occur to them their existing hardware could do better.

I know of no way to persuade a Windows video driver to ignore EDID it can actually see. This is an issue that goes all the way back to VGA. I first encountered it when trying to make Windows XP drive some Epson classroom projectors at their native panel resolution to avoid vertical blurring; the panels were 1280x800 but the EDID claimed they were 1280x720. The only way I could actually make it work involved physically breaking off the EDID pin inside the VGA connector so that Windows detected the projector as a "standard" monitor rather than a "plug and play" one.

Since EDID is an integrated, rather than optional, feature of digital video protocols like DVI and HDMI, that hack won't work with those. But if you end up not being able to find a way to bend your Windows driver settings to your will, there might still be workable hardware-based options based around the kinds of HDMI EDID emulators made for use with keyboard/video/mouse switches.

But if you're even contemplating spending money on hardware you might find that the path of least resistance is to do what an ordinary mass market non-Pi-owner would do and replace your TV. We recently picked up quite a decent 43" TV from our local tip shop for AU$100; I'd be surprised if you couldn't find a replacement 32" one with an actual 1080p panel for substantially less.
posted by flabdablet at 12:25 AM on April 25, 2021


Response by poster: Have you also tried creating a custom resolution of 1360x768 to try to get an exact match for what the Pi sends?

Yep! No dice - I can jump through some hoops in the nVidia control panel to force it, but it too goes as soon as anything happens (DPMS power-down, fullscreen app, source switch, reboot, TV power-down).
posted by Dysk at 1:12 AM on April 25, 2021


Response by poster: Since EDID is an integrated, rather than optional, feature of digital video protocols like DVI and HDMI, that hack won't work with those.

Actually it does - you can blank pin 19 to achieve a similar effect, though I don't know if it helps with this particular issue, people mostly use it to stop Windows reshuffling all their open apps and desktop icons onto screen 1 when screen 2 powers down and is thus seen as disconnected).

I want to do this without hardware modifications though, because I know this hardware can do it unmodified, it just wants to revert to upscaling the picture to 1080p for my TV to then downscale back (presumably Windows thinks 1080p is my panel's native res, since it's the biggest one it claims to support).

This was possible back in the VGA days - I remember having and solving almost this exact issue in Windows 2000 as a teenager with a hand-me-down monitor that could get great crisp images, but had some quirks out damage.

But if you're even contemplating spending money on hardware you might find that the path of least resistance is to do what an ordinary mass market non-Pi-owner would do and replace your TV.

This isn't really an option for me. The current TV is second hand as is, and I'm using it in place of a proper monitor because it's what I have, not by choice. I'd still be using my old CRT if modern devices had analogue output, or if cheap HDMI -> VGA adaptors could keep up with >60Hz refresh without getting blurry and audibly buzzy.
posted by Dysk at 1:22 AM on April 25, 2021


Response by poster: (And I could solve this problem in about ten seconds on Linux, if it ever even came up, but this second hand SFF office PC is what passes for a gaming PC in my life, so...)
posted by Dysk at 1:24 AM on April 25, 2021 [1 favorite]


How many of the EDID Override tools did you try and were any of the sampled EDID's from edid.tv helpful?
posted by k3ninho at 1:37 AM on April 25, 2021


Response by poster: The one and only Toshiba entry on EDID.tv resulted in a bright blue screen and a little box on my TV suggesting the source wasn't a valid video signal.

Again, I absolutely can set this resolution in Windows 10, it's just that it insists on reverting to 1920x1080 whenever anything display related happens. That is the behaviour I want to change.
posted by Dysk at 1:46 AM on April 25, 2021


Response by poster: Surely there's an easier way to achieve this than effectively modifying a display driver? Up until (and including) windows 7 you could just do a small registry key tweak and windows would stop trying to be cleverer than it is. Is that really impossible now?
posted by Dysk at 1:48 AM on April 25, 2021


Best answer: Okay, so it looks like MS has addressed this very issue since last time I looked, and some kind soul has built a thing for editing the required INF files. Don't fight with your display driver, just lie to it instead.

If this works, I'd like to know about it.
posted by flabdablet at 1:50 AM on April 25, 2021


Response by poster: That looks like it solved the problem (but what the fuck is this that it was possible to do through native tools on windows 2000, but requires me to manually specify the timings in an external app on windows 10? I shouldn't have to override EDID with custom settings, it should be possible to tick a box to ignore it, windows can set the right res out of the box, it just doesn't want to, and keeps reverting...)

But this totally works as a solution for me, so thanks!
posted by Dysk at 1:55 AM on April 25, 2021


I think it's to do with DirectX12 and the low-level handling of graphics outputs.
posted by k3ninho at 1:58 AM on April 25, 2021


what the fuck is this

In general I find that MS always provides the same answer to that question: "This behavior is by design."
posted by flabdablet at 2:00 AM on April 25, 2021 [1 favorite]


Response by poster: They're trying to do an Apple, I guess? But why they don't provide an option to turn the automation off, even in the registry like they did on win 7, when it clearly can send the required signal out the box...
posted by Dysk at 2:01 AM on April 25, 2021


To be fair, once you've committed as many code paths to pulling stuff out of EDID blocks as I'm quite sure the modern graphics stacks have done - especially given that some of this stuff runs in-kernel, some in userland, and some not even on the CPU - just providing a way to sub in an alternate EDID block probably is the tidiest and least edge-caseful way to deal with this from a code maintainability point of view.
posted by flabdablet at 2:12 AM on April 25, 2021


Response by poster: I guess? Linux/Xorg just lets you override the automatic settings in a configuration file (not referring here to the boot config for the Pi, which is its own weird way of doing stuff).
posted by Dysk at 6:13 AM on April 25, 2021


what the fuck is this that it was possible to do through native tools on windows 2000, but requires me to manually specify the timings in an external app on windows 10? I shouldn't have to override EDID with custom settings, it should be possible to tick a box to ignore it, windows can set the right res out of the box, it just doesn't want to, and keeps reverting...

The actual answer to this is that the Windows driver model has completely changed.
Starting with Windows 8 it exclusively uses WDDM drivers instead of the older XDDM drivers. This is also why you no longer have to reboot when updating your graphics drivers.
posted by neckro23 at 3:14 PM on April 27, 2021


Response by poster: My "why" is more of a rhetorical question and a complaint, really. At any rate, that answer merely pushes the question another layer deep: why doesn't WDDM allow a better solution?
posted by Dysk at 4:03 PM on April 27, 2021


To which the answer is the same as I alluded to upthread: because for the overwhelming majority of use cases for the platform it's part of, it doesn't have to.

Cobbling workable desktop installations together from second-hand hardware to save money and be ecologically responsible is a priority for a very small slice of Windows's user base; a slice, moreover, that is never going to make MS any money. WDDM doesn't implement features that would be nice for you to have because MS doesn't care at all about you. It's a corporation, not a community.

Which is, incidentally, the reason I run Debian and not Ubuntu.
posted by flabdablet at 7:50 PM on April 27, 2021


Response by poster: I mean, I get it, but I also fundamentally disagree. These are settings that are set somewhere, and the fact that a solution exists means I can manipulate it. This has nothing to do with the PC and would be exactly the same on a brand new computer, whether prebuilt or put together from parts. The issue is the display, not the computer.

So given that the setting exists, and that I can manipulate it, why make it maximally difficult to do so? Why not have it set in a text file or registry key?
posted by Dysk at 10:43 PM on April 27, 2021


Response by poster: >And the panel res is a resolution reported by the display as supported, it's just not the highest one reported as supported. This is Windows 10 (or nVidia, I guess?) insisting on doing the resolution scaling based on a guess on what the panel res is, rather than passing a signal resolution to the display that it actively reports as supported over EDID, because we couldn't possibly have the display do its own scaling.

The fact that their guess is wrong here is what makes it really a problem, but it's frustrating and baffling behaviour regardless. If my monitor reports a resolution as supported, it is because it can support it. Let me use it. If I prefer to have the display itself so the scaling, let me. There is no internt advantage to doing it on the GPU instead.
posted by Dysk at 10:55 PM on April 27, 2021


given that the setting exists, and that I can manipulate it, why make it maximally difficult to do so?

The implementation they've chosen - INF files that install a replacement EDID block into a registry key - is pretty close to minimally difficult for MS to roll out via Windows Update if they want to. MS gives zero shits if you, personally, want to be able to control your display driver settings; if they care about anything it will be minimizing the number of support calls they have to handle wrt poor performance on some display manufacturer's hardware, which they can do (once made aware that it's an issue) just by pushing out a Windows Update.

Now, they could have added EDID-editing functionality to the Control Panel, or adapted what they used to have in Windows 2000 to make it work with WDDM. But that's code they'd have to write, maintain, and support, all for the benefit of a tiny number of users who would even actually end up touching it. It's clearly just not worth their trouble.

Linux has a reputation for being user-hostile in part exactly because so much of it can be configured with a text editor rather than specialized config editing tools. Xorg.conf is actually a prime example of user-hostile design; the syntax is finicky and the concepts need some fairly deep X knowledge to make sense of. There are endless postings all over various Linux support forums offering arcane tweaks to Xorg.conf to deal with an endless variety of broken X behaviour; but over the years I've been running Linux, what actually needs to go in Xorg.conf has been progressively shrinking, and in fact for the last decade or so most installations haven't needed an Xorg.conf at all because so much of what it used to be in it is now supplied as automatic defaults based on EDID.

But unlike the current Windows graphics stack, X was not built from the ground up with EDID in mind. EDID blocks get translated to X config, not the other way around, and there's no extra code to write and maintain in order to supply custom X config because this stuff is all legacy anyway.

I'm expecting it all to get a bit harder once Wayland eventually manages to supersede X.

If I prefer to have the display itself so the scaling, let me. There is no internt advantage to doing it on the GPU instead.

Quite so, especially given that whatever the hell Windows uses under the hood for bitmap upscaling looks terrible compared to anything I've ever seen built into a display screen to do the same job.

There's a whole pile of scaling nonsense, both system-wide and per-app, that's been built into Windows versions from 7 onwards. Some of it works tolerably well some of the time; more often than not it screws things up completely. If you're having any kind of display scaling weirdness with Windows 10 it's always worth having a poke around in those settings to see if you can calm it down.
posted by flabdablet at 1:38 AM on April 28, 2021


Response by poster: adapted what they used to have in Windows 2000 to make it work with WDDM

This kind of misrepresents it, since whatever system they had in Windows 7 still allowed it. This isn't some ancient 90s tech I'm asking for.

if they care about anything it will be minimizing the number of support calls they have to handle wrt poor performance on some display manufacturer's hardware, which they can do (once made aware that it's an issue) just by pushing out a Windows Update.

The sheer number of threads on MS support forums I've found where people moan about this exact issue, get told by MS representatives to report it using the feedback tools built in to Windows, only to come back and grouse about the feedback never generating any response, sometimes months or years later, suggests that such a system for pushing updates doesn't work well at all. And that's just when searching for the specific model of TV I'm working with. There are going to be a lot of displays from the mid 00s that support 1080p by downscaling it, and it seems like Windows 10 just upscales for that case, always only to have the display then downscale it back to the actual selected resolution at the other end of the display cable. Which is never a good solution.
posted by Dysk at 11:58 AM on April 28, 2021


Response by poster: (And DPI or UI scaling are another kettle of fish, but I'm not using a resolution high enough for that to really matter - I have all UI scaling turned off, because 1366x768 is nothing like big enough to cause issues with stuff being too small on screen)
posted by Dysk at 12:01 PM on April 28, 2021


Just out of interest, what does your display's EDID specify as its preferred mode?
posted by flabdablet at 12:23 PM on April 28, 2021


Response by poster: 1920x1080.

Because it, like so many other (cheap) TVs of the era is a fucking liar. It's a way of allowing it to handle 1080p/i media sources (with downscaling) without crapping out or defaulting to 1280x720, and of course the actual panel res is not one that the sorts of things that were commonly connected to the TVs at the time (when analogue VGA was still dominant in PCs) ever even considered.
posted by Dysk at 12:54 PM on April 30, 2021


The sheer number of threads on MS support forums I've found where people moan about this exact issue, get told by MS representatives to report it using the feedback tools built in to Windows, only to come back and grouse about the feedback never generating any response, sometimes months or years later, suggests that such a system for pushing updates doesn't work well at all.

MS would be relying on Toshiba to generate the required EDID-overriding INF file and submit it as an OEM driver for pushing via Windows Update, and it looks like Toshiba hasn't done that because there's no profit for Toshiba in making stuff they sold so long ago work better for end users. Toshiba would obviously rather you bought a newer TV.

Again, these corporations fundamentally give no shits about anything but shifting units. They will make things easier for users only to the extent that doing so helps them sell more stuff.

And 1366x768 is a pain in the arse as panel resolutions go. It isn't a tidy aspect ratio like 16:9 or 16:10, the horizontal pixel count isn't a multiple of 8, and there's a fairly high likelihood that graphics drivers will not deal with it consistently. You're lucky, frankly, that your TV will actually let you display pixel-for-pixel video if you feed it 1360x768.

If MS were actually to make a good faith attempt at driving a plug-and-play fix for this issue, they'd need to be persuading Toshiba to provide them with updated EDID timings for all their 1366x768 panel devices, and testing those against a multitude of graphics drivers. This is a lot of work; far easier for MS to adopt the usual ¯\_ (ツ)_/¯ stance and just let users vent spleen on their (I agree, almost always completely useless) support forums. Doing so will cost them a very good approximation of zero business.

And again, MS is simply not interested in fixing this kind of thing in a way that isn't plug-and-play. The design trajectory of Windows (and commercial IT products in general) over the last twenty years has involved consistent reduction in the number of controls exposed for end users to tweak. UI is the single most expensive kind of code to maintain in an OS, so from a pure business perspective the more of it you can automate away the better. I'm quite convinced that the sole reason Windows has any kind of EDID override mechanism in it in the first place is because some engineer, having personally run into the same kind of issue as you, just did it, documented it, and then convinced their manager that leaving it in place would cost them nothing in additional support or code maintenance overhead on the exact basis that there isn't any UI for it.

Please don't mistake any of this for any kind of defence of MS's policies on moral grounds. It's not that, it's merely an attempt to communicate my best understanding of how decision-making works inside this kind of org. I personally find MS essentially indefensible on moral grounds, mainly because this kind of relentlessly capitalist logic dominates their design decisions to the extent that it does.
posted by flabdablet at 10:17 PM on April 30, 2021


Response by poster: Again, everything you say is true, but every version of Windows before 10 just let you pick your resolution without assuming that to mean you want to actually not change your resolution, but just apply some bullshit scaling to Windows' dictated, unchanging resolution.

Like, why even have a selection box that says "resolution" if you won't actually let me change the resolution? Literally every single operating system other than Windows 10 can do this simple, basic thing. Hell, Windows 10 retains a whole bunch of UI stuff that's based on the assumption that you can actually change resolutions when you pick a new resolution like the 15 second countdown to confirm the change before it reverts automatically. That's only necessary if you can select a setting that your monitor literally cannot display. Which isn't possible if you're only pretending to let the user change their resolution.

And calling using a third-party tool "having an EDID override" is kinda bullshit.

I'm really not that interested in the business case. I get that, it doesn't make them money. But modern OSes support a ton of things that don't directly make them money.

But really, the thing that frustrates and annoys me is that Windows 10 still goes through all the motions and acts like it will let you select a resolution, when it won't.
posted by Dysk at 10:53 PM on April 30, 2021


Response by poster: (Also the fact that the exact panel res of this particular TV is an odd corner case doesn't change the general point: lots of EDID for TVs from the same era cannot be trusted to actually tell you about the display hardware, and Windows 10 acts like it lets you change resolutions, but then quietly decides the user can't be trusted, and lies to you about actually doing so. The whole problem is lies compounded by lies. That at least is avoidable, and would actually mean less code for MS to maintain. Supporting changing resolutions would obviously be ideal, but ceasing the pretense if they won't would also do.)
posted by Dysk at 11:08 PM on April 30, 2021


15 second countdown to confirm the change before it reverts automatically. That's only necessary if you can select a setting that your monitor literally cannot display.

Also necessary if you've selected a resolution low enough to make dialog boxes of about that size overflow the screen to the extent that their buttons aren't reachable.

calling using a third-party tool "having an EDID override" is kinda bullshit.

The EDID override itself is implemented inside Windows, as registry keys where overriding EDID blocks for specific monitors get stored as REG_BINARY blobs, along with an INF-based mechanism for loading stuff into those registry keys, possibly via Windows Update. All that the third-party tool does is give you a nicer UI than Regedit for manipulating that stuff. You could still achieve an overridden EDID without the third-party tool, but doing so would involve fiddling with raw EDID bits using Regedit's inbuilt hex editor. It wouldn't be much fun.

the thing that frustrates and annoys me is that Windows 10 still goes through all the motions and acts like it will let you select a resolution, when it won't.

I've never encountered that behaviour on any of the many Windows 10 boxes I've played with, so I'm guessing it's some kind of intra-driver fallback for when the graphics driver and the UI and EDID are all lying to each other about what they can actually do, and I'm further guessing that this will turn out to be happening exactly because 1366x768 is such a pain in the arse.

I would be interested to find out what happens if you use the third-party tool to install an EDID override registry key that explicitly allows for a 1360x768 (not 1366x768) mode with exactly the same detailed timings that your Pi uses to achieve pixel-perfect output, then use the usual Windows UI to select 1360x768. My prediction is that Windows will then actually send that resolution rather than faking it, even if your customized EDID block does not list it as the preferred resolution.

The thing that annoys me about Windows 10 is that it clearly demonstrates MS continuing to double down on its long-standing tradition of assuming that MS knows far better than you do how you should be allowed to operate your own computer. This annoys me enough, and has been doing so for long enough, that I've been choosing not to use Windows nor any software that only runs on it, games included, on any of my own machines for the past twenty years.

Solving Windows issues is a pastime in its own right for me now, like doing the cryptic crossword. It's not something I'm ever forced to do because whatever needs fixing is blocking me from doing something else, and that's a genuine luxury.

The whole problem is lies compounded by lies.

I suspect that you and I might be in heated agreement at this point.
posted by flabdablet at 11:46 PM on April 30, 2021


Response by poster: I would be interested to find out what happens if you use the third-party tool to install an EDID override registry key that explicitly allows for a 1360x768 (not 1366x768) mode with exactly the same detailed timings that your Pi uses to achieve pixel-perfect output, then use the usual Windows UI to select 1360x768. My prediction is that Windows will then actually send that resolution rather than faking it, even if your customized EDID block does not list it as the preferred resolution.

Well yeah. But this is exactly how I solved my issue, except that I used the timings for the actual native panel res. It works the same whether I use the timings specified in DMT mode 86, 87,or 81 (just with that six pixel difference). I'm sure I could add an EDID override entry for 1024x768 and that would work as well, as long as I set the TV to expect a 4:3 signal.

My issue was that Windows faked any resolution but 1920x1080 before adding EDID overrides. Even when checking the box that says to allow setting of resolutions unsupported by the display. Even while telling me that it was changing the resolution.
posted by Dysk at 12:02 AM on May 1, 2021


The prediction that this weird fake-resolution behaviour is actually an artefact of the way your nVidia graphics driver and EDID are interacting, as opposed to a Windows issue per se, was largely based on observing that the graphics driver supplied with VirtualBox as a guest addition can support completely arbitrary dimensions for the virtual screen without triggering any visible Windows scaling behaviour.

My best guess is that Windows was telling the nVidia driver to run at 1366x768 (either because the monitor's non-overridden EDID says that's possible or because you've told it not to check), and then the graphics driver was going fuck, I actually can't do that because I don't like the detailed EDID timings for that mode or there aren't detailed EDID timings for that mode or 1366 % 8 != 0 or whatever bullshit reason, so I'll look for the next highest EDID-listed resolution I can generate and then use my amazing nVidia GPU superpowers to scale everything up to that without telling Windows that that's what I'm doing.

But whatever. I'm glad you got a result that works for you.
posted by flabdablet at 12:09 AM on May 1, 2021


Response by poster: It's got nothing to do with the weirdness of the timings on 1366x768. The behaviour was the same for any non-1920x1080 resolution I set.
posted by Dysk at 12:21 AM on May 1, 2021


Response by poster: (And it did tell Windows, which is why under "advanced display settings" it reported the "desktop resolution" as whatever I set, but the "active signal resolution" as always 1920x1080.)
posted by Dysk at 12:22 AM on May 1, 2021


None of that would make any sense to me at all unless I were to find out that... (goes digging) wait for it... this behavior is by design.

From page 300 of the Windows Hardware Compatibility Program document (locked filing cabinet, disused lavatory, beware of the leopard):
Description: WDDM2.0 drivers must report support for virtual resolution changes and DWMClone, via the new VirtualModeSupport member in DXGK_DISPLAY_DRIVERCAPS_EXTENSION, by setting VirtualModeSupport to 1 when the OS calls DxgkDdiQueryAdapterInfo on DXGKQAITYPE_DISPLAY_DRIVERCAPS_EXTENSION.
I'm sure there's a registry key somewhere that turns VirtualModeSupport off and restores the clearly unacceptable-to-the-modern-world brief blink on display resolution change, but before going digging for that you might care to find out whether your signal resolution does indeed match your specified resolution after a reboot.

Fucking Windows, hey. The only solution is more beer.
posted by flabdablet at 12:58 AM on May 1, 2021


Response by poster: For the moment at least, it's persistent across reboots, graphics driver updates, display source switches, display power cycles, and full screen app launch/close cycles (including ones that are running at a lower res than my desktop).

It's just absolutely maddening that I had to jump through all these fucking hoops to do something that is - on every other operating system I've used (raspberry pi wonkiness aside) including previous versions of Windows - literally just a drop down menu that's at most two clicks from an idle desktop. The fact that Windows 10 has that same drop down menu but then doesn't actually do what you ask it to is adding insult to injury.
posted by Dysk at 4:02 AM on May 1, 2021


For the moment at least, it's persistent across reboots

If what's persistent across reboots is the fact that your display signal resolution matches your specified resolution without scaling, as intended, then that's what I'd expect to see. More interesting, to me, would be the question of whether the following sequence happens if you undo all the EDID customization you've done to get to where you are now.

1. You pick some lower-than-1920x1080 resolution, and find that Windows is now scaling its desktop to that resolution while still running the display at 1920x1080, as originally reported.

2. You reboot.

3. You find that the Windows desktop is still set to the resolution you asked for and that the display is now being supplied with a non-scaled signal at that same resolution, i.e. there's no longer any upscaling to 1920x1080 happening on the Windows end of the cable.

If that's what's happening - if Windows actually can reduce resolution on the wire rather than faking it with scaling, but needs a reboot to get there - then that will be because of this new "virtual resolution change" anti-blink bullshit that's a "core feature" of WDDM 2.0.

If you can't make Windows put 1366x768 on the wire at all, even after a reboot, without first forcing the use of an EDID override that declares availability of and/or defines timings for that resolution, then that will be because your graphics driver is internally doing upscaling for non-EDID-defined resolutions even if Windows isn't explicitly asking it to.

I completely understand if you'd rather not risk breaking your now-working setup by bothering with this kind of beanplating. At some point I'll get my hands on a Windows box and a cheap TV and explore this issue myself. It's always nice to know exactly which layer(s) an issue is hiding in; makes the least-effort fix that much easier.
posted by flabdablet at 6:42 AM on May 1, 2021


Response by poster: I'm not going to undo it, but I do recall how it worked best case before I mucked with the EDID override: I could set it to 1366x768 and actually get that down the wire, but only after a reboot, and only if the display was off (or on a different source) when the computer booted. Then it would give me the correct res without scaling. I think I had to switch off GPU scaling in the nVidia control panel to even get that far.

And it only worked until the display power cycled, went into DPMS standby, was switched to a different source, you touched any resolution or scaling settings again, or a full screen app was launched. If you did much more than breathe on it, it was straight back to 1920x1080 and scaling, which could only be fixed by rebooting with the display off.

Needless to say this was not particularly workable as a solution.
posted by Dysk at 7:39 AM on May 1, 2021


What did your EDID override actually do? Was changing the preferred mode enough, or did you need to delete anything higher-res than 1366x768 entirely, or what?
posted by flabdablet at 8:58 AM on May 1, 2021


Response by poster: I used CRU to specify a new custom resolution, and input the standard DMT timings for 1366x768 60Hz and 1366x768 50Hz. Then I deleted the entry for 1920x1080.

CRU now reports two different EDID profiles for the TV, one which is the actual hardware EDID, and the active one, which is my new list (1366x768 60Hz, 1366x768 50Hz, and for some reason 720x576 50Hz - I didn't specify this, I think it's a derived option from the timings I did specify? Either way, it's last in the list and stuff works, so I'm not inclined to poke it too hard!)
posted by Dysk at 10:10 AM on May 1, 2021 [1 favorite]


« Older Where to stay in Chicago?   |   Help us name our new crawlbot, please. Newer »
This thread is closed to new comments.