Tabby: a tabbed-tiling wayland compositor

Docbroke · 2021-09-21 03:08:05

I am seeing another type of freezing issue which involves only tabbybar. The tabbybar works, but it's display is frozen. So if at the time of freeze there are three windows open, bar displays same three windows even if I close or open windows, similarly right side of bar has frozen clock/volume etc. However tabbybar seems to work internally, I can open applications using tabby-menu ( using pure muscle memory, and no visible output of tabby-menu on bar ). There is nothing in journal or tabby log at the time of freeze. I have noticed this 2-3 times in last 2 days.

EDIT:
I wish to have multi-language font support in tabby-bar, so that window titles in local language can also be displayed, ( when opening local websites for e.g.,). I see two possible ways 1. to have fallback font setup in fontconfig, I guess it is already there as terminal is able to display indic languages without changing font, but this is not the case with tabbybar, is there way to do that? or less preferably 2. create a font by merging different fonts so as to have all glyphs in one font.

Last edited by Docbroke (2021-09-21 08:26:40)

Trilby · 2021-09-21 12:04:31

The bar freeze is odd. I did just make a change to reuse rather than constantly recreate the texture of the bar - but if that were to fail, it should do so cotninuously, not sporadically. I've not seen any symptoms of that (yet) myself, so it'll be hard to debug.

The next time you see that happen, can you try running a tabby-config command that changes some aspect of the bar. The easiest might be to change a color - you could even change a color you don't use, for example, assuming you don't use color 5 anywhere:

tabby-config color5 0.0 0.0 0.0 0.0

Whether or not this triggers the bar to start working again right away will be informative.

For the font, I don't know much about how font-config works, but the font initialization done in tabby should include fallback fonts as defined / provided by fontconfig. Are you using the same font string for your terminal and for tabby? If not, can you try doing so? Could you give me a url or two that shows the issue so I could test?

Last edited by Trilby (2021-09-21 12:39:00)

Docbroke · 2021-09-21 13:05:52

Here are news channels in Gujarati, www.divyabhaskar.co.in , https://gujaratexclusive.in

EDIT2: I am consistently getting tabby-bar freeze this way, open divyabhaskar site, and click on any new article ( it will have title in gujarati) --> notice tabbybar freeze.

You may need "Noto Sans Gujarati", "Noto Serif Gujarati" or "padmaa". padmaa is in ttf-indic-otf (official package). Noto fonts can be downloaded from google.com/get/noto or one of the official noto fonts package.

I again noted bar freeze, when I opened above mentions news site. It may be related to this font display issue. tabby-config command didn't change anything.

EDIT: I did restart tabby (without logging out), so tabbybar restarted properly. Started weaver to find that input was not working. I did logout, login and started tabby again, still weaver input failed. This time I did save log and did reboot. Here is the log
https://termbin.com/97ri

EDIT3: this input issue may actually be related to me restarting ibus daemon. This is different from tabbybar freeze, which can be reproduced consistently now.

So Now I think I am getting 3 different freezes
1. tabbybar freeze, can be produced as stated above
2. weaver(running under tabby) input freeze with weaver, which is related with ibus running
3. tabby freeze, probably related with starting another compositor on other tty ( or may be due to some program starting with compositor)

Last edited by Docbroke (2021-09-21 13:32:17)

Trilby · 2021-09-21 14:20:25

I'm able to consistently replicate the 1st issue with the news website you provided. That allowed me to trace it to a cairo function call failing and giving an error indicating that the title is an invalid string. The title provided by that website is indeed not valid utf8 - and apparently wlroots doesn't include any checks for this. I'm looking into validating the titles myself, but from what I'm finding utf8 string validation code is as long as all the bar drawing code in tabby.

EDIT: it turns out this has nothing to do with the title being in a non-latin locale at all, but simply due to the titles not being valid utf8. And apparentrly cairo drawing contexts go into an unrecoverable state if a string function is given a non-utf8 string (which in itself is absurd and has been griped about on the cairo bug tracker for over 15 years). For now I've pushed a temporary workaround that checks if the cairo context is in such an unrecoverable state every time the bar is updated - if it is, the entire bar is reconfigured from scratch. In reality, this workaround will likely stay around long term as it is a good catch-all or any odd occurrences - but there really needs to be a better way to deal with these titles without having to rely on this mechanism.

EDIT 2: according to the xdg-shell protocol titles must be utf-8, so this is a client error. Of course that doesn't get me off the hook as the client in question is weaver (at least for me). But there the title setting is done by qt5 which seems to be violating the protocol standard. I'll look into this in weaver.

Last edited by Trilby (2021-09-21 16:18:09)

Docbroke · 2021-09-21 15:57:32

I found this https://cairographics.org/FAQ/#using_pango

It's not hard to run into some of the limitations of cairo_show_text. For example, it will only display glyphs from a single font. So if you happen to choose a font that doesn't provide glyphs covering every character in your string, then some characters just won't appear. It has a host of other limitations with respect to layout, ligatures, and shaping. We won't go into all of those details here, but suffice it to say that if you have any aspirations of having reasonable, internationalized text display in your application, then you don't want to be using cairo_show_text.
Meanwhile, the non-toy APIs in cairo, (cairo_show_glyphs and cairo_show_text_glyphs), are really hard to use. Compared to cairo_show_text, these still don't do any of the heavy lifting of text, but instead expect that the caller has done all of that already. So you could use these as the basis of a sophisticated text-layout engine, but chances are that you'd rather spend the next several years on your application instead.
Fortunately, the pango library exists and does do sophisticated text layout, shaping, etc. and integrates very nicely with cairo. We heartily recommend that "real" applications wanting to display text with cairo use pango to do it.

EDIT: the temporary workaround is nice, no more bar freeze.
It appears that fonts not displaying non-latin characters is related to cairo not supporting fallback fonts.

Last edited by Docbroke (2021-09-21 16:00:25)

Trilby · 2021-09-21 16:08:04

Thanks - I'll look into that.

EDIT: I just switched bar drawing over to pango. It seems to be working for now.

Last edited by Trilby (2021-09-21 17:02:51)

Docbroke · 2021-09-21 17:30:11

This is definitely good. The non-latin non-utf fonts are now visible, so it seems tabbybar shall not freeze now (even without temporary hack).
But still something is not right, few of the nerd font symbols I am using in tabbybar are not displayed properly. This is not a big issue though, as I can find alternative symbols. I am happy that non-latin characters are properly displayed by fallback fonts now.

Trilby · 2021-09-21 17:48:51

The format for specifying the font in the config file has changed. The previous font-config strings would not be recognized by pango - if you haven't updated your config, then perhaps it's just not using your intended font and so those symbols aren't availbale. Pango font strings are described here:

https://docs.gtk.org/Pango/type_func.Fo … tring.html

Docbroke · 2021-09-21 18:07:37

yes indeed. I had suspicion that fonts were looking different.
Now this looks beautiful, I feel that fonts are looking better than before.

Edit: do you think this may solve the issue with ibus too? I will try to use ibus anyway.
Edit2: no, ibus still leads to frozen input in weaver (this seems to be weaver specific, input works in other applications)
Edit: I just commented out ibus env. variable "export QT_IM_MODULE=ibus", so that weaver doesn't use ibus, problem solved, now I can use ibus with libreoffice, where it is actually needed.
Edit: fcitx5 works fine, so i just removed ibus.

Edit3: pango needs some config with ligatures, whenever " fi " is input it is replaced by telephone symbol.
Edit4: ligature seems font-specifc issue, after changing form notosansmono to notomono nerd fonts, issue disappeared.

Last edited by Docbroke (2021-09-22 07:42:33)

Docbroke · 2021-09-22 16:53:09

Noticed another full tabby screen freeze, while using weaver. This time there was no other wayland compositor was running, (fcitx5 was running, as I am trying that inplace of ibus)

2021-09-22T22:16:54: debug: src/settings.cpp (74) Settings::cookieFilter: "https://pyra-handheld.com/boards/service_worker.js"
03:54:31.488 [ERROR] [backend/drm/atomic.c:35] connector eDP-1: Atomic commit failed (pageflip): Device or resource busy
2021-09-22T22:17:18: qt.qpa.wayland.warning: unknown (0) unknown: Unexpected wl_keyboard.enter event. Keyboard already has focus
03:54:58.447 [INFO] [libseat] [libseat/backend/logind.c:316] Disabling seat
03:54:58.898 [INFO] [backend/drm/backend.c:134] DRM fd paused
The sink doesn't exit

The sink doesn't exit

03:55:28.137 [INFO] [libseat] [libseat/backend/logind.c:313] Enabling seat
03:55:28.665 [INFO] [backend/drm/backend.c:116] DRM fd resumed
03:55:28.665 [INFO] [backend/drm/drm.c:1297] Scanning DRM connectors on /dev/dri/card0
03:55:28.679 [INFO] [backend/drm/drm.c:808] connector eDP-1: Modesetting with '1920x1080@59999mHz'
03:55:30.526 [ERROR] [backend/drm/atomic.c:35] connector eDP-1: Atomic commit failed (pageflip): Permission denied
03:55:30.527 [INFO] [libseat] [libseat/backend/logind.c:316] Disabling seat
03:55:30.921 [INFO] [backend/drm/backend.c:134] DRM fd paused

Trilby · 2021-09-22 21:08:25

Thanks for the updates. I've not made any headway finding other sources of the atomic commit error. All info I can find suggests that is the result of rendering outside of a frame event from the monitor / output, but that's not happening in tabby.

Docbroke · 2021-09-23 03:26:52

All my testings suggests that these freezes are related with how tabby/weaver handles keyboard input. Can you try reproducing this freezes,
--> most consistent way is to run ibus

ibus-daemon -drx &

with environmental variable

export XMODIFIERS=@im=ibus
export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus

, probably only last line is important for weaver on wayland.
--> start weaver and try typing in some text input, this will show text input freeze.
--> freezing of entire tabby display is less consistent but still I think it is also related with running some text input daemon, as you might have noticed in above log which says

unexpxected wl_keyboard.enter event

EDIT: with no systray on tabby, you will not not have ibus systray icon, but input languages can be changed using

ibus engine <input_engine>

EDIT2: on different topic, is there way to edit input using tabby-menu, something like

weaver //info/%2 | tabby-menu  "Edit" <edit url> "weaver %s"

Here I pipe current url to tabby-menu, then edit it and send to back to weaver to open edited url.

Last edited by Docbroke (2021-09-23 03:44:19)

dogknowsnx · 2021-09-23 14:45:59

Quickly putting my oar in to compliment you on this nice little piece of software.

I had to first find a way to make wlroots work on my old hardware. Always grateful for WMs with a small footprint.
One minor "issue" I'm having is not being able to set my keyboard layout correctly in order to get QWERTZ, any help is appreciated.

Keep it up and thanks again!

Trilby · 2021-09-23 15:34:42

Docbroke, thanks for the additional info. I've put testing / tinkering with ibus on my list - I'm not sure how quickly I can get to it, but I definitely will get there.

---

Thanks dogknowsnx.

~~What hurdles did you face with wlroots? Did the package from the repos not work "out of the box", or was this on another distro?~~
(edit: nevermind this - I found your previous thread)

dogknowsnx wrote:

One minor "issue" I'm having is not being able to set my keyboard layout correctly in order to get QWERTZ, any help is appreciated.

There is much to do with input configuration that hasn't been touched yet. However, for keyboard layout, I believe that can be specified just with an XKB environment varibale - I think it'd be XKB_DEFAULT_LAYOUT. If this is set / exported prior to starting tabby, it should be picked up by xkbcommon which is used for processing keyboard input. If these environment variables aren't sufficient then options will eventually be added to Tabby for these settings, but for now there are none. On the flip side, any options that are easily set outside of tabby will not be duplicated - I strive for modularity, and anything that doesn't need to be handled by the compositor shouldn't be overriden by the compositor (without very good reason).

See `man xkeyboard-config` for the environment variables and potential values - the second (long) section is a list of layouts that could be specified in XKB_DEFAULT_LAYOUT including many qwertz options.

EDIT: I don't have other keyboart layouts to test with, but I just set XKB_DEFAULT_OPTIONS=caps:escape in my ~/.profile and relogged in, and now capslock is appropriately behaving as an escape.

Last edited by Trilby (2021-09-23 16:03:01)

dogknowsnx · 2021-09-23 17:48:57

@Trilby
Thank you for the quick response and explanation. I'm all set now by exporting

XKB_DEFAULT_LAYOUT=de

I really like the way Tabby tiles - feels very intuitive to me!
Looking forward to seeing this baby grow... (hope it will stay a child, though).

Docbroke · 2021-09-24 06:15:27

I am getting full tabby display freeze while using either of mpv or ffplay. This happens consistently, and I think you will be able to reproduce it. Just play some video, go forward, go backward few times and if you are lucky you will have frozen display. Change tty and come back to unfreeze. Log shows same atomic error.
EDIT: this time no ibus/fcitx was running.

Last edited by Docbroke (2021-09-24 06:34:06)

Trilby · 2021-09-24 12:59:43

Sorry, I'm not able to replicate this. I played a couple videos in ffplay and rapidly scanned forwards and back for a couple minutes, but had no issues.

Does this replicate on a wayland backend? To test, run another compositor (e.g., hikiri or sway) then launch tabby from within that other compositor. A tabby session will run as a window / surface under the other compositor and render to a wayland surface backend rather than the normal drm. Then open the video in that nested tabby session and try to replicate the issue. You may need to temporarily modify your configs in order to avoid clashes in keybindings (e.g., any keys that are grabbed by the top-level compositor will never reach tabby).

Last edited by Trilby (2021-09-24 13:24:41)

Docbroke · 2021-09-24 13:30:56

I will try this.

Here is log after tabby freeze while playing ffplay, again there is no ibus/fcitx or another window manager running, but still there is unexpected wl_keyboard.enter event.

qt.qpa.wayland: Unexpected wl_keyboard.enter event. Keyboard already has focus
Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached
Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached
Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached
Unable to send notification: Error calling StartServiceByName for org.freedesktop.Notifications: Timeout was reached
00:31:37.302 [ERROR] [backend/drm/atomic.c:35] connector eDP-1: Atomic commit failed (pageflip): Device or resource busy
00:31:49.598 [INFO] [libseat] [libseat/backend/logind.c:312] Disabling seat
00:31:49.598 [INFO] [backend/drm/backend.c:134] DRM fd paused
The sink doesn't exit

This part of log appeared after changing tty and coming back to tabby

00:33:28.804 [INFO] [libseat] [libseat/backend/logind.c:309] Enabling seat
00:33:29.237 [INFO] [backend/drm/backend.c:116] DRM fd resumed
00:33:29.237 [INFO] [backend/drm/drm.c:1297] Scanning DRM connectors on /dev/dri/card0
00:33:29.278 [INFO] [backend/drm/drm.c:808] connector eDP-1: Modesetting with '1920x1080@59999mHz'

EDIT:
I opened tabby under hikari. Playing video with mpv lead to flickereing with totally unwatchable video. Playing using ffplay lead to stdout in terminal open in tabby but video opened in a new window in hikari. Is this acceptable way to test, with video opened in hikar window ? I haven't noticed hang in 5 minutes I played but I am doubtful of this method.

Last edited by Docbroke (2021-09-24 13:45:43)

CarbonChauvinist · 2021-09-24 16:44:00

@trilby, can I ask how you're managing/starting your session(s)? Are you using something like greetd + wlgreet?

Trilby · 2021-09-26 02:55:57

I wasn't even aware of such tools - I just run tabby from my shell profile.

@Docbroke, I just ran into a pattern that's likely related to the freezes you've reported. I first found that in a recent log I did get an 'atomic commit failed' error. I suspected, then confirmed, that this error came whenever I changed to another tty. They were - at least in the current conditions - benign, and just indicate that tabby still tried to process another frame after switching to the other tty. I was able to avoid this error message in the log by putting a call to "blank" at the start of the "chvt" function (to "turn off" the monitor before handing it over to another tty). I'll need to figure out how to detect when it should be re-enabled before I push this change though. (edit: there is an "active" event with wlr_session that appears to serve this purpose).

But while I was tinkering with this I tried a bunch of variations on this. I found that if I try to rapidly switch back and forth between ttys where one is running tabby (regardless of whether the other is running a compositor, or just a getty), I get a complete freeze and need to reboot. So something is clearly wrong here and now that I can replicate it I should be able to make much better progress ... assuming this is related to the problem you are experiencing.

That said, I've been pretty busy with the dayjob for the past couple weeks and my code commits have dropped off a bit. I'm not sure how quickly I'll be able to track this down.

EDIT: scratch that, I tracked it down quite quickly. I just tested with sway, and I get the exact same results: a complete system lock up just from toggling back and forth between the sway tty and any other tty. So it's a wlroots issue. This also appears to be specific to the wlroots chvt function, as switching rapidly between tty's with /bin/chvt does not result in any such issues. Perhaps I'll just drop the chvt key binding.

EDIT: and the wlroots function is just a wrapper for libseat_switch_session from libseat / seatd, so any problem would be there ... and I think this package is quite new - from just a couple weeks ago.

Last edited by Trilby (2021-09-26 04:01:01)

Docbroke · 2021-09-26 04:03:44

This seems different, as I am not able to replicate this.
Infact when I get a freeze, changing tty unfreezes tabby.

Docbroke · 2021-10-30 18:25:49

tabby is now in alpinelinux official repository

Trilby · 2021-10-30 18:31:18

Cool, thanks. I'm thinking of switching a relatively unused system of mine over to alpine. But the dayjob has been insanely busy for the past few weeks so none of my software projects have received any attention ... plenty of use and testing with little TODO items stacking up, but no coding.

Docbroke · 2021-10-30 18:45:21

I recently switched to alpine on my primary device. So I asked there for few few applications I missed. As a result, now sdcv, libcalculate, and tabby are in official alpine repos.

bgc1954 · 2021-10-31 14:48:14

It's been a while since tinkering and loving Alopex and all the previous versions so I thought I'd take the plunge and try out tabby. Liking it and functionality is great. I don't do anything complicated so not noticing any issues but I'm trying to set a background wallpaper and setting alacritty transparency but not getting any results with setwallpaper and swaybg and not finding a whole lot of options in wayland. Just my newbieness showing I guess. Keep up the good work when you get the time.

Arch Linux

#76 2021-09-21 03:08:05

Re: Tabby: a tabbed-tiling wayland compositor

#77 2021-09-21 12:04:31

Re: Tabby: a tabbed-tiling wayland compositor

#78 2021-09-21 13:05:52

Re: Tabby: a tabbed-tiling wayland compositor

#79 2021-09-21 14:20:25

Re: Tabby: a tabbed-tiling wayland compositor

#80 2021-09-21 15:57:32

Re: Tabby: a tabbed-tiling wayland compositor

#81 2021-09-21 16:08:04

Re: Tabby: a tabbed-tiling wayland compositor

#82 2021-09-21 17:30:11

Re: Tabby: a tabbed-tiling wayland compositor

#83 2021-09-21 17:48:51

Re: Tabby: a tabbed-tiling wayland compositor

#84 2021-09-21 18:07:37

Re: Tabby: a tabbed-tiling wayland compositor

#85 2021-09-22 16:53:09

Re: Tabby: a tabbed-tiling wayland compositor

#86 2021-09-22 21:08:25

Re: Tabby: a tabbed-tiling wayland compositor

#87 2021-09-23 03:26:52

Re: Tabby: a tabbed-tiling wayland compositor

#88 2021-09-23 14:45:59

Re: Tabby: a tabbed-tiling wayland compositor

#89 2021-09-23 15:34:42

Re: Tabby: a tabbed-tiling wayland compositor

#90 2021-09-23 17:48:57

Re: Tabby: a tabbed-tiling wayland compositor

#91 2021-09-24 06:15:27

Re: Tabby: a tabbed-tiling wayland compositor

#92 2021-09-24 12:59:43

Re: Tabby: a tabbed-tiling wayland compositor

#93 2021-09-24 13:30:56

Re: Tabby: a tabbed-tiling wayland compositor

#94 2021-09-24 16:44:00

Re: Tabby: a tabbed-tiling wayland compositor

#95 2021-09-26 02:55:57

Re: Tabby: a tabbed-tiling wayland compositor

#96 2021-09-26 04:03:44

Re: Tabby: a tabbed-tiling wayland compositor

#97 2021-10-30 18:25:49

Re: Tabby: a tabbed-tiling wayland compositor

#98 2021-10-30 18:31:18

Re: Tabby: a tabbed-tiling wayland compositor

#99 2021-10-30 18:45:21

Re: Tabby: a tabbed-tiling wayland compositor

#100 2021-10-31 14:48:14

Re: Tabby: a tabbed-tiling wayland compositor

Board footer