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.
-mario