Ok. This took you again way longer than I hoped for, so I had to read up on this again, after a multi-day break of working on lots of other stuff, which took extra work time. Swift responses to my requests are always in your best interest.
By now it took me additional 150 minutes of so far unpaid work time, which is way too much to give away for free.
I now know from the logs and reading kernel source code why the attempts so far failed, and that no simple adding of new modes via xrandr or similar will work to get anything but 60 Hz or 120 Hz in fixed refresh rate mode. The driver is way more strict and picky in mode validation when it comes to eDP embedded display port panels like the MS Surface Pro 8âs builtin screen. The hack would have more likely worked on external displays, although they have their own timing related traps with non-native modes, causing temporal aliasing which may defeat the purpose.
There are still things one can try, but I need your lab to buy at least 2 extra work hours from the discounted package, following the instructions I sent you via private message already a couple of days ago on the PTB forum, before I can give further minimal advice based on my current findings. Buying 3 hours would be better, to properly pay for work time and have a bit of head-room in case further tweaking and work is needed.
Best,
-mario
[210 of 60 minutes paid support used â 150 minutes = 2.5 hours overtime.]
Also worth a try to give the system another heads upâŚ
echo off > /sys/class/drm/card0-eDP-1/status ; cat /sys/class/drm/card0-eDP-1/status ; sleep 1; echo on > /sys/class/drm/card0-eDP-1/status ; cat /sys/class/drm/card0-eDP-1/status
This will shutdown the panel for a second and then hopefully take on the override edid when virtually âreconnectingâ the virtually âunpluggedâ panel.
There are ways to install the edid permanently in the system, which is what weâd do if we find a working solution, but this should be the quick and dirty way to test if the edid override works - if it works, that isâŚ
Ok, scrap this. I tried myself and couldnât get edid_override to work on my own laptop, so lets do the proper override immediately instead, no risk, no fun!
Follow the instructions at the bottom of the following webpage:
Instead of the connector name string HDMI-A-1 use eDP-1 to override the EDID of the builtin display.
After a reboot, this should load the /lib/firmware/edid/override.edid file and use it as EDID, overriding the real EDID of the panel with the one I created. It adds a 100 Hz refresh mode in addition to the 60 Hz and 120 Hz mode. At least this method of overriding the EDID worked for me - I used a hacked test EDID that now runs my MS Surface Pro 6 panel with 50 Hz instead of 60 Hz.
Lets hope this does the trick, because all the paid support is used up again.
-mario
Note I edited out mention of an unrelated problemâŚ
Following those instructions got me a 100 Hz modeline on xrandr. I wasnât on the command line able to set the rate, but I could easily change it in Settings and then confirm with PTB.
Well that was a feat. Thank you very much, Mario.
I will post graphical results of VBLSyncTest once I figure out the graphics problems preventing plotting.
Good! So the issue as whole is that eDP panels or other builtin/hard-wired panels like in Laptops or embedded devices (e.g., eDP embedded Displayport connection, or LVDS on older laptops, or stuff like MIPI on embedded devices) do usually not have a builtin panel fitter or less advanced timing / display controllers (TCON). Often they can only handle one or a few very specific video modes. Therefore the low-level driver checks requested video modes especially strictly for compatibility with what is stored in the displays EDID data and rejects anything off.
Our previous approach of just defining a custom mode with xrandr would or might work on some external DP/HDMI/DVI/VGA displays with more advanced display controllers, although often also at various tradeoffs which might make those modes useless for vision science. Most digital panels only work with proper timing and visual quality at their native resolution and refresh rate, or some small special subset of those. Other modes trigger digital image post-processing in the panels panel fitter or TCON with unknown and uncontrollable effects on timing (lag, temporal aliasing, judder, blurring and filtering) and low level stimulus properties. One reason we recommend using always the native video mode + PTBâs advanced unique panel fitter (see PanelFitterDemo.m) if one needs different resolutions or image rotation or the like, to let PTB do the necessary processing on the gpu.
In case of eDP panels on Intel, the driver will reject any mode with a video resolution width x height or refresh rate other than the ones stored in EDID, at least in fixed refresh rate (FRR) mode. It took me over an hour of digging through logs and kernel source code to find this specific catch with eDP panels.
With a VRR capable panel and gpu one can side-step this by using PTBâs VRR mode, but as you could see from your plots, getting 100 Hz in VRR mode is not as stable as in FRR mode if all one wants is stable 100 fps. PTBâs current implementation could be improved a fair bit though with a bit of funding.
As the ultimate in VRR uses, I do have a very good VRR prototype for AMD + Linux, which drastically improves VRR timing and opens up new use cases, but again due to lack of funding by the majority of our short-sighted users, this work was put on hold for the foreseeable future before it could come to completion - especially sad as I consider that personal VRR pet project of mine the coolest innovation in timed visual stimulus presentation of probably the last two decades, and the prototype works so well. I guess our users will finally get what they pay for after allâŚ
In your case, what I did is take the original EDID of your panel (from the xrandr output you provided) and edited it with the âwxeditâ tool (Ubuntu 22.04: apt install wxedit) to replace one of the two 60 Hz modes (it has two 60 Hz and one 120 Hz mode) with a 100 Hz mode. The mode is identical to the original in all parameters except for the dot clock which was increased from 355.5 Mhz to 592.5 Mhz, then provide you with that mssurfacepro8edid_100HzFRR.bin file. The procedure i told you tells the Linux kernel during bootup to ignore the hardware provided EDID for the eDP-1 display connector and use the data in that file instead. Of note is that this trick only works up to dot clocks of about a bit more than 600 Mhz, different EDID surgery with different editing tools is required for modes beyond that. Also, adding more than one such mode would also have required more advanced tools and hackery and more paid work time, which is why i only provided you with a 100 Hz mode and not a 100 Hz and 75 Hz mode. Basically this pushes it as far as it gets on that panel without multiple additional hours of paid extra work.
The other EDID files are variations: The VRR one instead would have been a less good hack abusing VRR mode by restricting the allowable VRR range to 89-100 Hz instead of the regular 30-120 Hz. This would have made VRR useless for its actual purpose, but allowed to get mostly reliable 100 fps. Yet another EDID file combined both hacks into one EDID. But the file you use now is the optimal and least invasive solution for your 100 Hz use case. This method should also survive operating system upgrades etc.
Your touch screen troubles are not likely to be related to this, unless Microsoft would have made some very weird hardware choices in how they implement their touch controller, e.g., deriving some operating clock for the touch controller from the pixel clock driving the video refresh â iow. anything but 60 Hz or 120 Hz would throw the touch controller off its mission. One has to remember though that the touch screen implementation of the MS Surface Pro tablets, as a few other features in those MS tablets, is very unusual and non-standard, using some Intel proprietary technology, and needs special experimental code in both the Linux surface kernel and an iptsd user-space driver, both are developed and maintained by volunteers in their spare time. Thatâs the reason why you need a special kernel from the Linux surface project in the first place, instead of standard stock Ubuntu. So limitations or regressions are a possibilityâŚ
I guess you could just check if the touchscreen trouble only happens with the 100 Hz mode to rule out that possibility.
xrandr should let you select those 100 Hz as well, but probably you need the --rate parameter in this case. Or PTBâs own SetResolution() function.
Wrt. Matlab, recently they have some embarrassing bugs in the graphics and plotting backend wrt. Linux + Intel graphics â See following link for likely workaround until Mathworks fixes Matlab:
The bug doesnât affect PTB but breaks Matlabâs plotting. Another solution is to use Octave which is fine for many projects and has less bugs and compat issues and much better behaviour on Hi-DPI panels like the MS Surface Proâs, because a bunch of volunteers can do a better job in their spare time than Mathworks graphics team. I find Matlab painful to use on the MS-Surface because of the abysmal HiDPI handling. Even on MS-Windows Matlab is poor compared to Octave wrt. HiDPI panels.