lost pixel support in alacritty

joseluis commented 3 years ago

hi there, I was starting the work to update the rust bindings to the latest changes and I noticed that pixel support is not working for me, specifically:

ncdirect_check_pixel_support() doesn't detect it using the latest commit of the 'graphics' branch of ayosec's fork of alacritty, nor is detected in the latest kitty (I'm not sure if it should here or not).
the pixels PoC ends with "this program requires pixel graphic support". That confirms it for me.

But this becomes even more confusing because I'm trying also the version from feb 16th (commit fc87aaa4b10b), (downloaded again, I deleted my old copy) but the basic boxes.sh example doesn't work in it, but it did for me in feb 16th. That probably means the repository has suffered some hard pushes, something has regressed, and I can't pull the old working version anymore...

if you've been working in the old version of the graphics branch, it's better that you don't update it and pull the latest version in another folder if you want to test it...

If there's a bug in the latest version of the alacritty fork we should fill an issue.

joseluis commented 3 years ago

dankamongmen commented 3 years ago

good to see your name in my inbox again, my friend =]

pixel stuff is in tremendous flux but basic detection ought not have been broken. if i read you correctly, this is alacritty's sixel branch, and on 2021-02-16 things there were mostly working for you, and now they're not. boxes.sh is an alacritty thing, right? i.e. not our src/poc/boxes.c. i've never tested with the alacritty sixels branch; let me go ahead and get a copy.

dankamongmen commented 3 years ago

btw, adding a notcurses_debug_caps() function which will detail most of what your test-notcurses.sh is outputting; i've wanted such a thing for a minute.

joseluis commented 3 years ago

good to see your name in my inbox again, my friend =]

thanks, was feeling the call of the pixels

I deduce the that you are testing sixels in xterm only... I checked that it does works on xterm -ti vt340.I was hoping pixel mode would work with kitty too but it doesn't seem so.

That repo and that script are from the dev that's working on the sixel PR for alacritty. It's all in my post from feb 16

dankamongmen commented 3 years ago

I deduce the that you are testing sixels in xterm only... I checked that it does works on xterm -ti vt340.I was hoping pixel mode would work with kitty too but it doesn't seem so.

kitty ought definitely work; it's where i'm doing most of my development. indeed i am only testing sixels with xterm, and the forty thousand xterm resources makes it difficult to compare. here's my Xresources:

[grimes](0) $ cat ~/.Xresources | grep ^XTerm
XTerm*faceNameDoublesize: WenQuanYi WenQuanYi Bitmap Song
XTerm*faceName: Hack
XTerm*faceSize: 12
XTerm*renderFont: true
XTerm*decGraphicsID: 340
XTerm*decTerminalID: 420
XTerm*numColorRegisters: 256
XTerm*privateColorRegisters: true
XTerm*sixelScrolling: false
XTerm*sixelScrollsRight: false
XTerm*maxGraphicSize: 1980x1440
XTerm*utf8: 1
XTerm*eightBitInput: false
XTerm*allowWindowOps: False
XTerm*disallowedWindowOps: 1,2,3,4,5,6,7,8,9,11,13,18,19,20,21,GetSelection,SetSelection,SetWinLines,SetXprop
[grimes](0) $

dankamongmen commented 3 years ago

btw i broke sixel while fixing #1434, having only tested in kitty, bleh. it's now fixed in master.

dankamongmen commented 3 years ago

now really fixed. i hate that i can't get info from the terminal about the state of bitmap rendering, and thus effectively can't close the loop on unit tests :(.

joseluis commented 3 years ago

kitty ought definitely work; it's where i'm doing most of my development.

What version are you using? Neither the last release 19.3 from december nor the one on master are detecting pixel support for me. Is there any special configuration or something?

dankamongmen commented 3 years ago

0.19.3

dankamongmen commented 3 years ago

we don't even have to perform bitmap detection on kitty (you can, and we should be, but right now we just assume Kitty graphics protocol support if you seem to be running kitty). apply_term_heuristics from terminfo.c. what TERM do you have?

dankamongmen commented 3 years ago

we really should move to interrogating the terminal for this support, but i'd like to know why it's failing for you.

joseluis commented 3 years ago

applied that environmental configuration in the kitties, but now the pixel program it core dumps in kitty and still works in xterm... I'm gonna have to close for today though.

joseluis commented 3 years ago

solved.

the bug was my TERMINFO env variable pointed to a location for the kitty-xterm under /usr, probably from an old configuration from when I was testing the version of kitty included in ubuntu, which I uninstalled today, I was running the new ones from a local path...

but that made me realize that in kitty the picture PoC works better than in xterm, because in xterm the picture appears under the text planes, not at the top.

dankamongmen commented 3 years ago

but that made me realize that in kitty the picture PoC works better than in xterm, because in xterm the picture appears under the text planes, not at the top.

yep, this is the stuff i'm working on actively for #1388. any asshole can display some bitmaps in a terminal. unifying the kitty protocol with sixel (and soon iTerm2 (#1420)), and the rest of the Notcurses z-axis multipile model, is by far the most complex aspect of all this. it's finally coming together, though.

dankamongmen commented 3 years ago

so i'm hearing from you that kitty is resolved, having removed an old bogon terminfo file (this seems to happen more often that i would have ever expected. you're like the third person. wtf is going on?), but alacritty is still open?

joseluis commented 3 years ago

that's it, alacritty still doesn't work for me. I'm curious if it does work for you

dankamongmen commented 3 years ago

i'll get that fork checked out or patch applied or whatnot and try it out whenever i can.

dankamongmen commented 3 years ago

here's how the alacritty code responds to a "Send Device Attributes" escape (https://invisible-island.net/xterm/ctlseqs/ctlseqs.html):

write(3, "\33[c", 3)                    = 3
read(3, "\33", 1)                       = 1
read(3, "[", 1)                         = 1
read(3, "?", 1)                         = 1
read(3, "4", 1)                         = 1
read(3, ";", 1)                         = 1
read(3, "6", 1)                         = 1
read(3, "c", 1)                         = 1

this indicates "VT132 with Advanced Video and Graphics"

CSI Ps c  Send Device Attributes (Primary DA).
            Ps = 0  or omitted ⇒  request attributes from terminal.  The
          response depends on the decTerminalID resource setting.
            ⇒  CSI ? 1 ; 2 c  ("VT100 with Advanced Video Option")
            ⇒  CSI ? 1 ; 0 c  ("VT101 with No Options")
            ⇒  CSI ? 4 ; 6 c  ("VT132 with Advanced Video and Graphics")
            ⇒  CSI ? 6 c  ("VT102")
            ⇒  CSI ? 7 c  ("VT131")
            ⇒  CSI ? 1 2 ; Ps c  ("VT125")
            ⇒  CSI ? 6 2 ; Ps c  ("VT220")
            ⇒  CSI ? 6 3 ; Ps c  ("VT320")
            ⇒  CSI ? 6 4 ; Ps c  ("VT420")

          The VT100-style response parameters do not mean anything by
          themselves.  VT220 (and higher) parameters do, telling the
          host what features the terminal supports:
            Ps = 1  ⇒  132-columns.
            Ps = 2  ⇒  Printer.
            Ps = 3  ⇒  ReGIS graphics.
            Ps = 4  ⇒  Sixel graphics.
            Ps = 6  ⇒  Selective erase.
            Ps = 8  ⇒  User-defined keys.
            Ps = 9  ⇒  National Replacement Character sets.
            Ps = 1 5  ⇒  Technical characters.
            Ps = 1 6  ⇒  Locator port.
            Ps = 1 7  ⇒  Terminal state interrogation.
            Ps = 1 8  ⇒  User windows.
            Ps = 2 1  ⇒  Horizontal scrolling.
            Ps = 2 2  ⇒  ANSI color, e.g., VT525.
            Ps = 2 8  ⇒  Rectangular editing.
            Ps = 2 9  ⇒  ANSI text locator (i.e., DEC Locator mode).

i've only been looking for Ps=4. this response from Alacritty suggests that VT132 should be interpreted as supporting sixel. @ayosec himself seems to say this (i could only find this link https://githubmemory.com/@ayosec?page=2, search for VT132).

i think this is wrong. the VT132 did not support sixel. furthermore, you'd better believe that xterm when configured to appear as a VT132 will not support sixel, and if you go interrogating it about sixel, who knows what will happen.

so i'm surprised that this ever picked up alacritty as supporting sixel, if it's always been doing this vt132 business, but i think alacritty needs to identify itself as at least a 220 with sixel support if it's going to do sixels, otherwise xterm and alacritty will diverge on vt132 behavior.

dankamongmen commented 3 years ago

i went and did some complaining in https://github.com/alacritty/alacritty/pull/4763

dankamongmen commented 3 years ago

We had some action over there, and things are just about working. Hopefully they'll make a final change I asked for. If not, we'll have to work around it.

dankamongmen commented 3 years ago

it looks like i'm going to have to query XTSMGRAPHICS on a DSA of 6c, sucks sucks sucks

dankamongmen commented 3 years ago

alright, it's in there, though not in the form i'd like.

joseluis commented 3 years ago

reopening because after that commit alacritty is no longer detected as having pixel support.

@dankamongmen what's the plan?

dankamongmen commented 3 years ago

reopening because after that commit alacritty is no longer detected as having pixel support.

@dangerousben what's the plan?

right now i'm not seeing alacritty reply to XTSMGRAPHICS, which it definitely was on the graphics branch last week. i also need to rigourize the Device Send Attributes lexer so it doesn't admit problems like those seen in #1506.

even if that happens, though, i played around with using '1' on my sixels for background type, and still couldn't get transparency out of alacritty as suggested in their bug. so i'm rather dismayed by the alacritty implementation as stands, though it's all very possibly my mistakes and fault.

dankamongmen commented 3 years ago

st is another example of a terminal which reports CSI ? 6 c to "Send Device Attributes", but doesn't answer to XTSMGRAPHICS, and thus violates the claims of the Alacritty authors =[. if i used the strategy they recommend / require, i'd lock up on st (indeed as seen in #1506).

i guess i can detect a VT102 in combination with a TERM value including alacritty, and turn them on then.

in any case, we still seem to lack transparency in alacritty sixels. it's kind of a downer that they managed to fuck things up this badly. do you want to go read the bug, including my comments, and see if i'm just missing something obvious?

dankamongmen commented 3 years ago

in any case, the alacritty hack is present in dankamongmen/directstream.

dankamongmen commented 3 years ago

we should be working in alacritty whenever ayosec/graphics is merged. i just tested there, and we work correctly. on that branch, XTSMGRAPHICS is supported, so we can enable the dynamic query once it's merged and widely available. emitting a sixel to alacritty without support is swallowed, but it still fucks up blitter decay, so i've explicitly disabled it on alacritty for now. i'll enable that as soon as ayosec/graphics is merged.

dankamongmen / notcurses

lost pixel support in alacritty #1430