deleting bad probed modeline
Hi, TLDR: I came upon a need to disable a reported modeline, cause it is not working and there is a legacy binary application that stumbles upon it. Looks like there is no tool for that? Longer version: there is a legendary 1999 game Heroes of Might & Magic III, which had been released for Linux by Loki games. The game itself is 100% playable on a modern FreeBSD (I bet on Linux, too). The game switches to 800x600 with XF86VidModeSwitchToMode API call. Before that it lists available modes with XF86VidModeGetAllModelines and chooses _the last_ 800x600 mode from the list. Since it is a binary file we can't fix that. My fairly modern laptop Thinkpad X1 Carbon Gen7 reports these 800x600 modes: [51.809] (II) modeset(0): Modeline "800x600"x60.0 81.00 800 832 928 1080 600 600 602 625 doublescan +hsync +vsync (75.0 kHz d) [51.809] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz d) [51.809] (II) modeset(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz d) This is how they are seen with xrandr --verbose: 800x600 (0x6d) 81.000MHz +HSync +VSync DoubleScan h: width 800 start 832 end 928 total 1080 skew0 clock 75.00KHz v: height 600 start 600 end 602 total 625 clock 60.00Hz 800x600 (0x6e) 40.000MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew0 clock 37.88KHz v: height 600 start 601 end 605 total 628 clock 60.32Hz 800x600 (0x6f) 36.000MHz +HSync +VSync h: width 800 start 824 end 896 total 1024 skew0 clock 35.16KHz The server easily switches to the first one: >xrandr --output eDP-1 --mode 800x600 But explicitly being asked for the third one it fails after a screen blink: >xrandr --output eDP-1 --mode 0x6f xrandr: Configure crtc 0 failed Same happens if I try to play Heroes III - it fails to switch the mode, cause it picks the last one from available 800x600s. See that if server is compiled with debug: [76.795] SwitchToMode - scrn: 0 clock: 36000 [76.795]hdsp: 800 hbeg: 824 hend: 896 httl: 1024 [76.795]vdsp: 600 vbeg: 601 vend: 603 vttl: 625 flags: 5 ... [76.796] Checking against clock: 36000 (36000) [76.796] hdsp: 800 hbeg: 824 hend: 896 httl: 1024 [76.796] vdsp: 600 vbeg: 601 vend: 603 vttl: 625 flags: 5 [76.815] (EE) modeset(0): failed to set mode: No such file or directory To confirm that, I quickly hacked the server not to report this mode via XF86VidModeGetAllModelines and after that Heroes sucessfully run. So, looks like my laptop reports something it can not do and there is no way to override that. Looks like hardware reported modes are not allowed to be deleted via randr API: >xrandr --delmode eDP-1 0x6f X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 19 (RRDeleteOutputMode) Serial number of failed request: 32 Current serial number in output stream: 33 Reading through sources it seems the old API XF86VidModeDeleteModeline still can delete it, but is there any working tool left that uses it old API? xvidtune seems to be not functional at all. Any ideas? Sidenote: using legacy X.org Intel driver instead of modeset, I would not see the second mode, but only first and faulty third one. Problem remains: [ 67928.274] (EE) intel(0): failed to set mode: Invalid argument -- Gleb Smirnoff
Re: deleting bad probed modeline
On Tue, Oct 01, 2024 at 08:21:21AM -0400, Vladimir Dergachev wrote: V> > While I can solve the particular problem for myself (hack the sources), my point V> > is that X.Org needs a generic tool to filter out modes reported by hardware, cause V> > some of them can be completely faulty (my case) or just undesired by a user. V> V> Maybe I am missing something, but you could specify modelines in xorg.conf V> and then only those modelines are reported. At least that how thing used to V> work last time I tried it. This is how it worked long time ago :) Now you normally do not specify any modelines in the xorg.conf, instead the hardware reports more than 30 supported modes and you can switch beetween them all. Of course, another workaround for me would be to include all these 30+ modes into my xorg.conf and then delete the problematic one. Or I can just leave a handful of modes that I actually use, just like in the old times. But the modern x.org aims for 100% autoconfiguration and modes reported by hardware is definitely a big win over the old times. btw, thanks X.org team for that! With the modern approach the right configuration knob would be a possibility to filter out certain modes reported by hardware, rather then falling back to old times when you needed to list them all. -- Gleb Smirnoff
Re: deleting bad probed modeline
Carsten, On Mon, Sep 30, 2024 at 09:49:50AM +0100, Carsten Haitzler wrote: C> > Reading through sources it seems the old API XF86VidModeDeleteModeline still C> > can delete it, but is there any working tool left that uses it old API? C> > xvidtune seems to be not functional at all. C> > C> > Any ideas? C> C> xvidtune was never really working (well) anyway. it was a poor extension... :) C> C> what you probably want is an LD_PRELOAD to just override xvidtune calls just C> for this program and have it filter/change responses. :) this is what i've done C> various times in the past for misbehaving apps i wanted to tame. Not a solution for this particular app, as it is statically linked. Actually this fact keeps it functional on a modern system after so many years. While I can solve the particular problem for myself (hack the sources), my point is that X.Org needs a generic tool to filter out modes reported by hardware, cause some of them can be completely faulty (my case) or just undesired by a user. -- Gleb Smirnoff
