ncplayer is defaulting to ascii in wezterm

[dankamongmen]

see https://github.com/wez/wezterm/issues/217. we're defaulting to ascii(!) in wezterm, and -bpixel doesn't successfully override it.

[dankamongmen]

notcurses-info properly detects rgba pixel graphics, and displays an image.

[wez]

FWIW, it picks ascii with both wezterm -n --config enable_kitty_graphics=false and wezterm -n --config enable_kitty_graphics=true

[dankamongmen]

.nodnod should have it fixed shortly, embarrassing

[dankamongmen]

we've got vopts->blitter == 6 even in perframe() hrmm

[dankamongmen]

so this has got to be a ncplayer problem, right? since it looks like things work fine in notcurses-demo

[dankamongmen]

rmmm you can switch to pixel at runtime by pressing '6'; that works fine

[dankamongmen]

ok we're getting 1 in the introduction of perframe()...

[dankamongmen]

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

[dankamongmen]

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?

[dankamongmen]

ahhhh no ok this is cruft on startup input. run notcurses-input in wezterm and it's obvious.

[dankamongmen]

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]

[dankamongmen]

that's an XTGETTCAP response

[dankamongmen]

hrmm XTGETTCAP is supposed to end in an ST, right? but i don't think we're seeing an ST here

[dankamongmen]

alright, i'm pretty sure this is a wezterm bug (see above). closing this upon confirmation.

[dankamongmen]

confirmed fix present in WezTerm 20220327-194806-1cf0a76f