13:05 <lynxeye> flto: since you reversed those parts, maybe you remember: does the 128B TS mode actually work with sampler TS? For me it seems to only produce corrupt colors in the second 4x4 color tile. 256B mode works fine.

13:09 <flto> lynxeye: since I documented a bit for it in the sampler, I think it should work.. but I don't remember

13:12 <lynxeye> flto: The bit you documented seems to have an effect, in that it cleared tiles are read correctly in 128B mode, but only half of the actually written tiles are correctly decompressed...

13:13 <flto> maybe the 128B mode just doesn't work with compression? in etna_screen_resource_alloc_ts I made it always use 256B with compression

13:15 <flto> I don't remember if compressed scanout needs 128 or 256.. if it uses 128 then I'd assume there's a way to make the sampler work..

13:16 <lynxeye> Yep, it might be buggy. 128B with compression works fine with the DCSS DEC400 decompression, though. Which means I now have a NULL intersection between the compression formats for scanout and sampler :/

13:17 <lynxeye> yes, the DCSS DEC400 compression can only deal with the 128B TS format

13:19 <flto> it wouldn't be the first time there is a problem like this (imx6q) ;-)

13:20 <lynxeye> *sigh*

13:29 <lynxeye> hah! seems there are more bits in the TX_CTRL

13:33 <lynxeye> Ah, bit 7 in TX_CTRL seems to control compression. Now I wonder why this wasn't an issue with 256B mode, maybe this one implies compression.

13:37 <flto> interesting, there's already another bit for compression in TS_SAMPLER_CONFIG

13:40 <lynxeye> TS_SAMPLER seems to be partially ignored, at least the TS_ENABLE bit is ignored and only TX_CTRL enable bit is taken into account