How to get non-standard resolutions #11
Comments
|
The timings seem to be controlled by the mode number, which is 0x8100 in the example above. I have been getting them from the wireshark usb captures from the windows driver. The CEA numbers seem to work, but I'm not able to guarantee there's no issues since I didn't see them in the wireshark captures. There might be other mode numbers from 0-0xFF that you can experiment with. Either that or there might be some additional registers to set to allow custom resolutions. I'm not sure since I don't have the register map. As a quick test you can get the mode that has the closest clock rate to your mode and replace the width and height with your custom resolution. |
|
Okay, but how do the CEA VIC numbers translate to the mode number? https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#CTA_Data_Blocks Probably I am using the wrong table? Table 3 in the CTA‐861-G standard states the same: |
|
I don't they they are using the CEA VIC numbers exactly, maybe only the lower numbers. The higher mode numbers doesn't seem to correspond to anything as far as I can tell. I haven't really tried changing the mode numbers, but you might be able to quickly try see what resolutions do the mode numbers represent using the python script in that repository. |
|
Hi, |
|
Thank you for the information (which might also be helpful for other users), but until now it seems that I can not configure the chip to output 400x1280. Some information:
I guess the second byte determines something related to color, since changing it to 0x4002 or 0x4003 gives the image a magenta overlay for me. I figured out the 800x1280 0x1100 by brute forcing. Since the chip seems to only support landscape formats, I don't think it's worth a try to go through all the combinations. Maybe it is possible to edit the firmware or pass custom timings, but I don't have too much hope in this adapter. It's sold as an USB 3.0 device, has a blue (!) USB 2.0 connector, its mass storage interface is very annoying and the reset logic upon starting is also quite questionable. |
|
@tablesturn @Bastindo : If those modes work, I don't mind accepting it as a PR to support additional modes. However, supporting interlaced modes needs an additional field in One possible way would be to set the mode, dump the registers and set another mode and compare the difference to see if the video mode timings can be set from there. As for the USB connector thing, I have a connector that has the full usb 3.0 pins, but none of them are connected. It is a common occurrence. Real USB 3.0 devices do exist though in #7 . |
|
I tried dumping the registers. Found a few more modes in 312aabc. |
I am using the code from here: https://github.com/s12wu/ms912x-python/tree/main
It is based on your driver and works just fine for my purpose (auxiliary display output from Python/Touchdesigner) with standard resolutions (e.g. 1920, 1080, 60, 0x8100, MS912X_PIXFMT_UYVY).
Since there is more activity right here and the problem is not related to the actual implementation, I am posting the problem in this repo.
The problem is that I want to use a display with a non-standard resolution of 400x1280.
It advertises the following EDID information, which is not a CEA mode:
Is there a way to get this resolution working, or are the timings hard-coded into the MS912x?
When using the resolution of 400x1280 in combination with any of the mode values from the ms912x_mode_list in ms912x_drv.c, the display just shows gibberish (as it does with Macrosilicon's suspicious Windows driver).
The text was updated successfully, but these errors were encountered: