Re: [dev] [dwm] Bluetooth XF86 keys not working
On 1/16/23 22:23, Storkman wrote: On January 17, 2023 3:03:52 AM UTC, Anskrevy wrote: I've got XF86XK_AudioPlay bound in my config.h with the necessary include file, and this hotkey works when I use my keyboard. However, when sent from a pair of bluetooth headphones the hotkey isn't triggered. I've got the following xev output which shows the two keys are slightly different This was actually recently fixed. https://git.suckless.org/dwm/commit/89f9905714c1c1b2e8b09986dfbeca15b68d8af8.html So I was reinventing the wheel. Thanks for pointing this out!
[dev] [dwm] Bluetooth XF86 keys not working
I've got XF86XK_AudioPlay bound in my config.h with the necessary include file, and this hotkey works when I use my keyboard. However, when sent from a pair of bluetooth headphones the hotkey isn't triggered. I've got the following xev output which shows the two keys are slightly different Bluetooth event from xev: KeyPress event, serial 34, synthetic NO, window 0x1c1, root 0x6b2, subw 0x0, time 1714630, (-534,257), root:(623,303), state 0x0, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES, XKeysymToKeycode returns keycode: 172 XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False Keyboard event from xev: KeyPress event, serial 34, synthetic NO, window 0x1c1, root 0x6b2, subw 0x0, time 1664827, (-534,257), root:(623,303), state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False In line 3 of the xev output from the bluetooth event the keycode is 208 instead of 172 which is returned by XKeysymToKeycode. Looking at the output of xmodmap -pk | grep -E "(172|208)" we get: 172 0x1008ff14 (XF86AudioPlay) 0x1008ff31 (XF86AudioPause) 0x1008ff14 (XF86AudioPlay) 0x1008ff31 (XF86AudioPause) 208 0x1008ff14 (XF86AudioPlay) 0x (NoSymbol) 0x1008ff14 (XF86AudioPlay) Formatted to look better. At this point I've just got a lot of information but I'm not sure how to get dwm to grab keycode 208 or why it's even different in the first place. The only solution I can think of is adding a modified Key struct where the KeySym is a KeyCode instead. This would require modification to the grabkeys function or another function all together. The keypress function would also need to be modified as there would now be two arrays to search through. I couldn't find a patch regarding this so I don't think I'm reinventing the wheel. However, I do think my solution is poor and because of that I'd like to know if anyone can think of cleverer solution to this issue. Thanks for reading.
Re: [dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni
On 10/30/22 13:36, NRK wrote: On Sun, Oct 30, 2022 at 12:50:54PM -0700, Anskrevy wrote: And here is my valgrind output https://gist.github.com/Anskrevy/b981453fb7fbe3fb410ac1dd883d23ad Looking at the backtrace it doesn't seem like it generated anywhere from libsl (or your program) ==2726510== 288 (256 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 192 of 320 ==2726510==at 0x4841888: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==2726510==by 0x49E9F25: FcPatternObjectInsertElt (fcpat.c:525) ==2726510==by 0x49EE180: FcPatternObjectAddWithBinding (fcpat.c:711) ==2726510==by 0x49FC079: UnknownInlinedFun (fcpat.c:1258) ==2726510==by 0x49FC079: UnknownInlinedFun (fcxml.c:3109) ==2726510==by 0x49FC079: FcEndElement (fcxml.c:3234) ==2726510==by 0x4D2E61E: doContent (xmlparse.c:3047) ==2726510==by 0x4D2BCB3: UnknownInlinedFun (xmlparse.c:2612) ==2726510==by 0x4D2BCB3: doProlog (xmlparse.c:4893) ==2726510==by 0x4D2D7CC: prologProcessor (xmlparse.c:4598) ==2726510==by 0x4D31879: XML_ParseBuffer (xmlparse.c:2009) ==2726510==by 0x49F67E4: FcConfigParseAndLoadFromMemoryInternal.lto_priv.0 (fcxml.c:3544) ==2726510==by 0x49F7136: _FcConfigParse.lto_priv.0 (fcxml.c:3679) ==2726510==by 0x49F7319: UnknownInlinedFun (fcxml.c:3447) ==2726510==by 0x49F7319: _FcConfigParse.lto_priv.0 (fcxml.c:3638) ==2726510==by 0x49FA2F5: UnknownInlinedFun (fcxml.c:2606) ==2726510==by 0x49FA2F5: FcEndElement (fcxml.c:3156) In any case, I don't think libsl should call FcFini because we don't know if the user is done with fontconfig or not and the FcFini documentation states [0]: | Frees all data structures allocated by previous calls to fontconfig | functions. Fontconfig returns to an uninitialized state, requiring a new | call to one of the FcInit functions before any other fontconfig function | may be called. The last line (requiring a new...before any other functions may be called) makes me question if it's even okay that fontconfig functions are being called without initializing the library. ST calls FcInit during setup [1], dmenu/dwm doesn't. Maybe they should ? I'm not really sure, the fontconfig documentation doesn't seem to say anywhere (aside from that line in FcFini docs) weather initialization is required or not. [0]: https://www.freedesktop.org/software/fontconfig/fontconfig-devel/fcfini.html [1]: https://git.suckless.org/st/file/x.c.html#l1144 - NRK > Looking at the backtrace it doesn't seem like it generated anywhere from > libsl (or your program) Very true. That made me consider filing an issue in the fontconfig repo. But then I saw the documentation on FcFini and after adding that my leak was gone. > In any case, I don't think libsl should call FcFini Agreed. However, I do think a comment about it is worth considering.
Re: [dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni
On 10/30/22 10:47, NRK wrote: On Thu, Oct 27, 2022 at 01:19:28PM -0700, Anskrevy wrote: Any program using libsl, or calling FcIni (directly or indirectly), that does not call FcFini results in a small memory leak. dwm and dmenu are effected by this. I do not see any call to FcInit in libsl, nor do I see any such call in dmenu/dwm. Running dmenu master branch under leak-sanitizer doesn't show any leaks related to fontconfig (v2.13.1) either. How exactly did you detect this leak? And are you sure this is a problem on libsl/dmenu/dwm side and not the library itself leaking things? - NRK I was mistaken. I thought that one of the Fc calls in drw.c was indirectly calling FcInit but after searching the fontconfig code base I don't think that is the case. As for how I found the leak I was using valgrind. You can try out this small program. Here is the Makefile https://gist.github.com/Anskrevy/52fa06719ad204cc99eb190bf20ddd84 Here is the source code https://gist.github.com/Anskrevy/c33a4ea0455a592d04b8a917eaf6737c And here is my valgrind output https://gist.github.com/Anskrevy/b981453fb7fbe3fb410ac1dd883d23ad Adding a call to FcFini in the x_cleanup function results in zero bytes being lost. I got similar output when using valgrind on dmenu. I believe it would be the same with dwm but have yet to test it out yet.
Re: [dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni
On 10/28/22 01:20, Hiltjo Posthuma wrote: On Thu, Oct 27, 2022 at 01:19:28PM -0700, Anskrevy wrote: Any program using libsl, or calling FcIni (directly or indirectly), that does not call FcFini results in a small memory leak. dwm and dmenu are effected by this. Appending a call to FcFini in the cleanup function will fix this. Wouldn't it just free the memory on program exit by the operating system? In this case I don't see the issue becaus it doesn't memory leak over time. Let me know if I missed something, You are correct. I was trying to find the leak in a program I am developing and found that this call resolved it. For those newer who use other suckless programs as reference when writing their own it might be nice to have a note about this function. Mention of it in the comment above drw_fontset_create would be my suggestion.
[dev] [libsl][bug] Call FcFini on cleanup for projects calling FcIni
Any program using libsl, or calling FcIni (directly or indirectly), that does not call FcFini results in a small memory leak. dwm and dmenu are effected by this. Appending a call to FcFini in the cleanup function will fix this.
