Some initial work towards making DECRQCRA less wrong#513
Conversation
Right now it should correctly compute the checksum for any region of the display that the host has written to completely. If any cells in the DECRQCRA region are erased, then the checksum will be incorrect as erased cells should not be included. Additionally, colour information is not currently included in the checksum - that still needs to be done too. And lastly, the checksum is only valid for the latin1 charset - for other VT420/520 charsets further work will need to be done.
This is required for DECCARA and DECRARA which do not affect erased cells when in stream mode, and also by DECRQCRA which excludes erased cells from the checksum. As it's only the three VT420 control sequences that pay attention to whether a cell is in the erased state or not, this change hasn't been fully rolled out to other emulations which all ignore this attribute and may or may not always clear it appropriately when a cell is written. Mostly its the protected field stuff that may still need further work.
It wasn't checking that the character specified was within the valid range, and it wasn't translating from the currently selected remote character set to the local one. When in UTF-8, no translation is applied and the entire base multilingual plane is allowed. Also adjusted DECERA so that it only erases non-erased cells.
rtolxlat normally masks off the 8th bit if the bytesize is set to 7 bits, but we don't want to do that here.
Or if page 0 is specified. Confirmed results match my VT520 when K95 is set to four pages.
Plus some other minor corrections.
…o DECRQCRA-fixes
| /* If the colour is outside the valid range for a VT525, convert it | ||
| * to the VT525 palette. We'll leave the regular SGR colours as-is. | ||
| * TODO: The VT525 only supports the 8 regular ANSI SGR | ||
| * colours; should we be mapping all colours to the | ||
| * 0-7 range? | ||
| */ |
There was a problem hiding this comment.
Note that the VT525 does actually make use of all 16 colours in its palette. You can assign the default colours to values outside the 0-7 range with DECAC, and those values will then end up written to the buffer when you output text with default attributes.
A similar thing can occur with the the DECATC mappings when using one of the DECSTGLT alternate text colour modes.
There was a problem hiding this comment.
ahh, I had wondered just want the purpose of having a 16 colour palette was when SGR only allowed setting 8 different colours! That makes sense, and also means the current code should be correct enough!
I think all that I'm missing now is handling of character sets beyond latin1. Last year I threw together a script to try and figure out what values the VT520 assigned to various characters outside of latin1, but doing anything with it would still require mapping those values to whatever unicode codepoints k95 is using. But that is starting to feel like a bit too much yak shaving given the real underlying project here is being able to test the DECLRMM stuff in a more automated fashion as I work through it all.
There was a problem hiding this comment.
@davidrg In case you do ever decide to add support for the other character sets, I've dumped my notes on the subject in an issue here: j4james/vtdocs#2
And it's worth pointing out that the VT420 checksum is actually quite a bit different from the VT520 and VT525. This is something that I only just discovered after doing some testing in blaze (which I'm assuming is an accurate representation of the real thing).
There was a problem hiding this comment.
Awesome! I've added a new ticket (#519) so that I remember to get this done at some point, as it would be nice if it properly copied the VT420/VT520/VT525 behaviours - especially once I get enough implemented to add dedicated emulation options for those terminals.
- Save results to a log file as well for easier diffing - Create a .gitignore file so test results are ignored - Save the terminal screen contents as a text file as well, and link it
and add a TODO for the future to maybe someday deal with other character sets
2 participants
Right now it should correctly compute the VT420 checksum for any region of the display that the host has written to completely. If any cells in the DECRQCRA region are erased, then the checksum will be incorrect as erased cells should not be included. Additionally, colour information is not currently included in the checksum - that still needs to be done too. And lastly, the checksum is only valid for the latin1 charset - for other VT420/520 charsets further work will need to be done.
So, still to be done: