The rofi widget (https://github.com/DaveDavenport/rofi), such as that which can be displayed with the command rofi -show run, does not receive keyboard inputs of any kind within the sway session. Mouse inputs do work properly.
As a result of the said command, XWayland logs a variation of:
XIO: fatal IO error 11 (resource temporarily unavailable) on X server ":0"
after <number> requests (<another number> known processed) with 0 events remaining
I have been able to run rofi under Weston without a hitch, and with that I would believe that the cause did not originate from rofi, input drivers, or Wayland itself.
ghost
All 31 comments
Seems like something has been broken in recent commits. I was able to use rofi in sway without any problem just a day before yesterday.
ghost
on 28 Nov 2015
I run rofi like this: https://github.com/mikkeloscar/dotfiles/blob/33677ef833823eb1e679f3549a58177536b527f5/.config/i3/config#L39
it does work, but rofi doesn't get focus so you have to move the mouse to rofi before you can type. It has always been like that with sway for me.
mikkeloscar
on 28 Nov 2015
Yes, confirm that. Just didn't pay attention to this before.
ghost
on 28 Nov 2015
Can everyone here report their version of Xwayland please?
ddevault
on 28 Nov 2015
I have: xorg-server-xwayland 1.18.0-3 from archlinux.
mikkeloscar
on 28 Nov 2015
I have the same.
ghost
on 28 Nov 2015
Just tested out rofi on xorg-* 1.17.4, works fine.
ddevault
on 28 Nov 2015
I also have the Arch Linux xorg-server-xwayland 1.18.0-3 package installed.
ghost
on 28 Nov 2015
@WokSearedBacon how do you run rofi -show run I noticed it works if I run it from urxvt rather than my usual terminal termite. I don't know why yet, but it might help narrow it down.
mikkeloscar
on 28 Nov 2015
Maybe something to do with termite running as a native wayland program, and urxvt running under Xwayland?
FreeFull
on 28 Nov 2015
It also works well with lxterminal running.
ghost
on 4 Dec 2015
@mikkeloscar I have the same focus issue using your rofi parameters. It does work given a click before any keypress, though!
ghost
on 4 Dec 2015
@mikkeloscar I run rofi using the sway config's exec command.
ghost
on 4 Dec 2015
I can confirm this issue. I start rofi with exec and it doesn't accept keyboard input.
NateBrune
on 11 Dec 2015
Can also confirm, though I found that mouse clicking isn't necessary, any mouse activity will work, and not just on the rofi 'window' to gain focus, like @mikkeloscar .
Secondly, upon initially starting sway from a tty, nothing renders (except the mouse in the top left corner), until I move the mouse. Then the wallpaper and swaybar show up and I can start interacting with sway.
I'm currently running sway-git-r1027.f994f00 (2015-12-18 branch "master"), and wlc-git-r824.6421f28 from the arch linux packages, which I understand are a bit out of date at this point.
EDIT: Updated to 23df7ed, still happens (but I love my i3blocks working perfectly now!)
StephenBrown2
on 23 Dec 2015
This is still an issue for me, xorg-server-xwayland is 1.18.3-1 and sway is 0.7-1 (Arch Linux).
I noticed that launching rofi via $mod+d on a workspace running a xwayland application works (and you can launch e.g. urxvt afterwards and rofi will receive input), but launching it on an empty workspace or a workspace running a Wayland application (e.g. termite) makes rofi not receive any input events. Any way to fix that?
embik
on 29 May 2016
I have the same issue but as soon as I open a urxvt terminal rofi is able to receive keyboard input. If the workspace is empty rofi will not receive keyboard input.
DaanDeMeyer
on 6 Jul 2016
@DaanDeMeyer I join. I use Gnome Shell on Wayland, instead urxvt - conky with own_window_type =
desktop. Also keyboard input prevent running Gtk3-applications.
ghost
on 7 Jul 2016
rofi deals with the keyboard in a weird way. It might be best to start discussions upstream about a native wayland port.
ddevault
on 7 Jul 2016
Same problem here on archlinux with rofi 1.2.0-1, xorg-server-xwayland 1.18.4-1 and sway-git r1969.ce713ef-1.
jpotier
on 11 Oct 2016
Same issue here with albert.
When close on unfocus is enabled, the launcher closes immediately unless the desktop is empty.
The window is clickable, but it is impossible to enter text.
nlgranger
on 13 Mar 2017
Gonna close this because it's not really sway's problem.
ddevault
on 14 Mar 2017
As far as I can tell, Rofi is now working fine even when it is started on an empty workspace.
However, I just noticed that the focus problem is still happening after switching to an empty desktop while Rofi (or dmenu) is running:
Steps to reproduce:
(1) Start rofi with something like printf "aaa\nbbb\nccc\nddd\n" | rofi -dmenu
(2) Switch to an empty workspace using a keyboard shortcut
(3) The keyboard focus is lost. The mouse still works but clicking on the rofi window does not provide keyboard focus.
(4) The keyboard focus can be obtained by switching to a non-empty workspace
schauveau
on 16 Jul 2019
I was able to reproduce the above with a different procedure. I have 3 displays when I'm at work.
1) start rofi
2) give focus to anything on a different display
3) rofi cannot regain keyboard, as focus remains on the "anything" from point 2 (mouse does work though)
4) clicking on anything on the same display rofi is at has no effect
5) clicking on anything on the _third_ display close rofi though
Just putting this here, could be useful to someone stumbling upon this issue, as it's a way to close rofi when it loses keyboard input that doesn't involve clicking on some app you don't wanna open anyway.
luispabon
on 17 Jul 2019
info:
OS:
Manjaro Gnome.
Situation:
1.With mouse focused on brave browser and with alacritty open. (with wayland)
2.With mouse focused on alacritty terminal or empty workspace. (with wayland)
3.With mouse focused on brave browser and with alacritty open. (with xorg)
4.With mouse focused on alacritty terminal or empty workspace. (with xorg)
(Not much of sample space)
Ok I did some research. Here is what I came back with:
When your are in situation 1, 3 and 4. Rofi will work as intended. Keyboard focus goes to rofi and I can type away.
When in situation 2. Rofi just won't take the keyboard focus.
hope this helps for something
(Yeah I know no sway but it proves that it has to do with whatever that sway, xorg ang wayland are called)
tusqasi
on 28 Jul 2020
Stop writing reproduction steps, start writing patches
ddevault
on 28 Jul 2020
tbf since I posted here a year ago I switched to wofi, which is wayland native. https://github.com/nwg-piotr/nwg-launchers has a dmenu replacement too.
luispabon
on 28 Jul 2020
There is also an active fork of rofi working on wayland support: https://github.com/lbonn/rofi
DaveDavenport
on 28 Jul 2020
Stop writing reproduction steps, start writing patches
How can I?
I am happy to help.(but not in coding. Yet)
(I thought to have steps to reproduce it will help, 'coz other times people are telling to give those.)
tusqasi
on 29 Jul 2020
Here is a small bash script that uses 'swaymsg -t get_outputs' to obtain the focused output and rofi -m to force the monitor.
The script is not entirely automatic. The output names and the monitor numbers must be edited to match your configuration.
schauveau
on 30 Jul 2020
I just figured out tthat rofi -m also accepts names instead of numbers. However, those names are not the Wayland output names but the X11 screen names as returned by xrandr.
Fortunately, It seems that swaymsg -t get_outputs and xrandr are printing their outputs in the same order so my previous script can be automated:
rofi-sway-2.sh.gz
That version should hopefully be more robust when some outputs are disabled.
schauveau
on 30 Jul 2020
Related issues
J0nnyMak0
路
3Comments
StephenBrown2
路
4Comments
ghost
路
4Comments
emersion
路
4Comments
jakubn551
路
4Comments