Closed dankamongmen closed 2 years ago
notcurses-info
properly detects rgba pixel graphics, and displays an image.
FWIW, it picks ascii with both wezterm -n --config enable_kitty_graphics=false
and wezterm -n --config enable_kitty_graphics=true
.nodnod should have it fixed shortly, embarrassing
we've got vopts->blitter == 6
even in perframe()
hrmm
so this has got to be a ncplayer
problem, right? since it looks like things work fine in notcurses-demo
rmmm you can switch to pixel at runtime by pressing '6'; that works fine
ok we're getting 1 in the introduction of perframe()
...
whoa this is all over the place!
[schwarzgerat](0) $ less f
BLITTER: 6 vopts.blitter: 6
PERFRAME: 6 6
vopts.blitter: 6 marsh.blitter: 6
vopts.blitter: 6 marsh.blitter: 6
vopts.blitter: 6 marsh.blitter: 6
vopts.blitter: 1 marsh.blitter: 1
vopts.blitter: 1 marsh.blitter: 1
vopts.blitter: 1 marsh.blitter: 1
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 4 marsh.blitter: 4
vopts.blitter: 4 marsh.blitter: 4
vopts.blitter: 4 marsh.blitter: 4
vopts.blitter: 4 marsh.blitter: 4
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 6 marsh.blitter: 6
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 5 marsh.blitter: 5
vopts.blitter: 4 marsh.blitter: 4
CALL ZE STREAMER
PERFRAME: 6 6
vopts.blitter: 6 marsh.blitter: 6 0x000000000000001b
vopts.blitter: 6 marsh.blitter: 6 0x0000000000000050
vopts.blitter: 6 marsh.blitter: 6 0x0000000000000031
vopts.blitter: 1 marsh.blitter: 1 0x000000000000002b
vopts.blitter: 1 marsh.blitter: 1 0x0000000000000072
vopts.blitter: 1 marsh.blitter: 1 0x0000000000000035
vopts.blitter: 5 marsh.blitter: 5 0x0000000000000034
vopts.blitter: 4 marsh.blitter: 4 0x0000000000000034
vopts.blitter: 4 marsh.blitter: 4 0x0000000000000045
vopts.blitter: 4 marsh.blitter: 4 0x000000000000003d
vopts.blitter: 4 marsh.blitter: 4 0x0000000000000035
vopts.blitter: 5 marsh.blitter: 5 0x0000000000000037
vopts.blitter: 5 marsh.blitter: 5 0x0000000000000036
vopts.blitter: 6 marsh.blitter: 6 0x0000000000000035
we're getting a steady stream of input under wezterm, that's what's going on! possibly related to pixel-mouse events?
ahhhh no ok this is cruft on startup input. run notcurses-input
in wezterm and it's obvious.
process_escape:2128:initialized automaton to 1
process_escape:2140:walk result on 80 (P): 0 387
process_escape:2140:walk result on 49 (1): 0 393
process_escape:2140:walk result on 43 (+): 0 394
process_escape:2140:walk result on 114 (r): 0 395
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 52 (4): 0 396
process_escape:2140:walk result on 52 (4): 0 396
process_escape:2140:walk result on 69 (E): 0 396
process_escape:2140:walk result on 61 (=): 0 396
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 55 (7): 0 396
process_escape:2140:walk result on 54 (6): 0 396
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 55 (7): 0 396
process_escape:2140:walk result on 65 (A): 0 396
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 52 (4): 0 396
process_escape:2140:walk result on 54 (6): 0 396
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 55 (7): 0 396
process_escape:2140:walk result on 50 (2): 0 396
process_escape:2140:walk result on 54 (6): 0 396
process_escape:2140:walk result on 68 (D): 0 396
process_escape:2140:walk result on 59 (;): 0 396
process_escape:2140:walk result on 49 (1): 0 396
process_escape:2140:walk result on 43 (+): 0 396
process_escape:2140:walk result on 114 (r): 0 396
process_escape:2140:walk result on 53 (5): 0 396
process_escape:2140:walk result on 50 (2): 0 396
process_escape:2140:walk result on 52 (4): 0 396
process_escape:2140:walk result on 55 (7): 0 396
process_escape:2140:walk result on 52 (4): 0 396
process_escape:2140:walk result on 50 (2): 0 396
process_escape:2140:walk result on 61 (=): 0 396
process_escape:2140:walk result on 56 (8): 0 396
process_escape:2140:walk result on 47 (/): 0 396
process_escape:2140:walk result on 56 (8): 0 396
process_escape:2140:walk result on 47 (/): 0 396
process_escape:2140:walk result on 56 (8): 0 396
process_escape:2140:walk result on 59 (;): 0 396
process_escape:2140:walk result on 49 (1): 0 396
process_escape:2140:walk result on 43 (+): 0 396
process_escape:2140:walk result on 114 (r): 0 396
process_escape:2140:walk result on 54 (6): 0 396
process_escape:2140:walk result on 56 (8): 0 396
process_escape:2140:walk result on 55 (7): 0 396
process_escape:2140:walk result on 48 (0): 0 396
process_escape:2140:walk result on 54 (6): 0 396
process_escape:2140:walk result on 49 (1): 0 396
process_escape:2140:walk result on 61 (=): 0 396
process_escape:2140:walk result on 27 ( ): 0 398
walk_automaton:570:unexpected transition on 398[91]
that's an XTGETTCAP response
hrmm XTGETTCAP is supposed to end in an ST, right? but i don't think we're seeing an ST here
alright, i'm pretty sure this is a wezterm bug (see above). closing this upon confirmation.
confirmed fix present in WezTerm 20220327-194806-1cf0a76f
see https://github.com/wez/wezterm/issues/217. we're defaulting to ascii(!) in wezterm, and
-bpixel
doesn't successfully override it.