dnkl changed the topic of #foot to: Foot - fast, lightweight and minimalistic Wayland terminal emulator || 1.16.2 || https://codeberg.org/dnkl/foot || channel logs: https://libera.irclog.whitequark.org/foot
mx08 has quit [Quit: WeeChat 3.8]
boomboxnation has quit [Quit: WeeChat 4.2.1]
boomboxnation has joined #foot
boomboxnation has quit [Client Quit]
boomboxnation has joined #foot
boomboxnation has quit [Remote host closed the connection]
boomboxnation has joined #foot
boomboxnation has quit [Client Quit]
boomboxnation has joined #foot
<dnkl> since the hashes of the codeberg generated release tarballs change every now and then, I've decided to attach static tarballs (+ .sig files) to the releases. I've "backported" this for fcft-3.1.8, foot-1.16.2 and wbg-1.1.0, but plan on doing this for all my projects going forward
<sewn> why do they change
<bookworm> because the underlying git pack thing was never guaranteed to be stable, the compression especially
<bookworm> and as people assume that hashing the compressed files is a valid thing to do that screws it up
<sewn> why doesn't codeberg make it stable? i thought it was a good git service
<sewn> this makes distribution of foot etc kinda hard, i've seen issues being made on kiss-community for this exact reason
<sewn> (shameless advertisement for sourcehut)
<rjarry> dnkl, sewn, bookworm: weird that this is not constant, git archive --format=tar.gz seems to produce stable output
<rjarry> I only tested this on signed tags though
qyliss has quit [Quit: bye]
qyliss has joined #foot
emersion has quit [Remote host closed the connection]
emersion has joined #foot
<bookworm> there's also an upstream discussion on the git ML
<bookworm> it caused quite the stir also on GH
sefidel has quit [Remote host closed the connection]
sefidel has joined #foot
sentriz has quit [Ping timeout: 264 seconds]
<sewn> sourcehut my beloved
sentriz has joined #foot
boomboxnation has quit [Remote host closed the connection]
boomboxnation has joined #foot
<manio> guys, I am now using foot version: 1.16.2 +pgo +ime +graphemes -assertions from Arch
<manio> today I encounter for the second time a foot which is eating 100% cpu core
<manio> instead of killing this as yesterday I just attached to this using gdb
<manio> I still have it attached in case you're interested to do something...
<dnkl> looks like it's in a poll. Be interesting to know if the busy loop around the poll is entirely in libwayland, or in foot
<rjarry> just tested it and it seems not working as expected
<rjarry> with numlock active, shift+space does not output a printable character https://0x0.st/HR7e.txt
<rjarry> 130 is shift+numlock if I'm not mistaken
cbb has joined #foot
<dnkl> rjarry: judging from the version output, you're on the wrong branch/commit
<dnkl> rjarry: what's weirder though, is if it reports NumLock itself as an active modifier
<dnkl> it means your keymap is reporting it as enabled, but *not locked*
<dnkl> i.e you're holding it down
<rjarry> huh
<rjarry> I am not holding it
<dnkl> not saying you are, but that's what the keymap says
<rjarry> what is the correct branch/commit to apply this patch on?
<dnkl> just check out the "kitty-is-text" branch
<rjarry> ack
<dnkl> but if I'm right about it not being locked, I doubt using the correct branch is going to help
<rjarry> I'll test that right away
<dnkl> you could also try setting LOG_ENABLE_DBG to 1 in input.c, do a debug build, and run foot with "-d debug"
<dnkl> then you'll get detailed logs when you press/release keys, including modifier state
<dnkl> manio: we might get somewhat more information if you could catch the bug while running foot with WAYLAND_DEBUG=1
<rjarry> missing another build option it seems
andyrtr has quit [Quit: ZNC 1.8.2 - https://znc.in]
andyrtr has joined #foot
<cbb> rjarry: -Dbuildtype=debug
<cbb> (when running meson, that is)
<rjarry> cbb: how can it influence the foot log level argument parsing?
<manio> dnkl: will try, but don't know if/when it'll happen again
<cbb> rjarry: _DEBUG isn't defined in non-debug builds, so log_level_from_string() excludes it
<cbb> excludes parsing "debug" as a valid log level I mean
<rjarry> oh !
<rjarry> I had missed the sneaky map_len()
<rjarry> weird to exclude it like that, ok
<rjarry> cbb: still fails, for some reason
<rjarry> I checked with gdb, and it "works" when stepping
<rjarry> but not outside gdb
<rjarry> nevermind, I was using -d dbg
<rjarry> not working, it needs -d debug
<cbb> the map_len() hack was my doing
<cbb> it's used in 2 places, but maybe there's a clearer way to do it
<rjarry> I would expect that -d debug is available even in non debug builds
<cbb> yeah, I was just about to say that
<cbb> I agree
<rjarry> unless there is a serious perf degradation because of it
<cbb> always recognize it, but give an error message noting that it's disabled
<rjarry> but since you're not disabling debug logs at compile time, it should not affect
<rjarry> or is it disabling logs at compile time?
<rjarry> dbg: input.c:1572: pressed: space (32/0x20), seat=seat0, term=0x10da080, serial=476499, mods=Shift (0x00000001), consumed=<none> (0x00000000), locked=Mod2 (0x00000010), repeats=1
<rjarry> whatever Mod2 is :)
<cbb> rjarry: I'm guessing it's numlock
<rjarry> looks like it
<cbb> it should be shown in the `xkbcli interactive-wayland` output if you press the numlock key
<rjarry> ~$ xkbcli interactive-wayland
<rjarry> Command 'interactive-wayland' is not available
<rjarry> sad
<cbb> rjarry: which distro?
<rjarry> fedora
<rjarry> there is interactive-evdev
<rjarry> but I don't know if this is the one foot uses
<rjarry> interactive-evdev output gives:
<rjarry> keycode [ LFSH ] keysyms [ Shift_L ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ ] leds [ ]
<rjarry> keycode [ SPCE ] keysyms [ space ] unicode [ ] layout [ English (US) (0) ] level [ 0 ] mods [ Shift ] leds [ ]
<cbb> if it's numlock, I think you probably have to toggle num lock on and press some other keys
<cbb> and Mod2 should be listed in "mods"
<rjarry> I didn't change anything
<rjarry> numlock is fixed by sway
<cbb> ah ok, I guess that could change what it reports
<cbb> just to be clear, I'm not interpretting this stuff in the context of the original problem... just trying to help gather the needed info
<rjarry> no worries
<rjarry> I think the issue is with numlock (mod2) being fixed by sway, it seems to change the way it is reported
<rjarry> maybe foot shouldn't care about locked modifiers ?