'rofi' not receiving keyboard input

[ghost]

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]

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.

[mikkeloscar]

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.

[ghost]

Yes, confirm that. Just didn't pay attention to this before.

[ddevault]

Can everyone here report their version of Xwayland please?

[mikkeloscar]

I have: xorg-server-xwayland 1.18.0-3 from archlinux.

[ghost]

I have the same.

[ddevault]

Just tested out rofi on xorg-* 1.17.4, works fine.

[ghost]

I also have the Arch Linux xorg-server-xwayland 1.18.0-3 package installed.

[mikkeloscar]

@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.

[FreeFull]

Maybe something to do with termite running as a native wayland program, and urxvt running under Xwayland?

[ghost]

It also works well with lxterminal running.

[ghost]

@mikkeloscar I have the same focus issue using your rofi parameters. It does work given a click before any keypress, though!

[ghost]

@mikkeloscar I run rofi using the sway config's exec command.

[NateBrune]

I can confirm this issue. I start rofi with exec and it doesn't accept keyboard input.

[StephenBrown2]

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!)

[embik]

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?

[DaanDeMeyer]

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.

[ghost]

@DaanDeMeyer I join. I use Gnome Shell on Wayland, instead urxvt - conky with own_window_type = desktop. Also keyboard input prevent running Gtk3-applications.

[ddevault]

rofi deals with the keyboard in a weird way. It might be best to start discussions upstream about a native wayland port.

[jpotier]

Same problem here on archlinux with rofi 1.2.0-1, xorg-server-xwayland 1.18.4-1 and sway-git r1969.ce713ef-1.

[nlgranger]

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.

[ddevault]

Gonna close this because it's not really sway's problem.

[schauveau]

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

[luispabon]

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.

[tusqasi]

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)

[ddevault]

Stop writing reproduction steps, start writing patches

[luispabon]

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.

[DaveDavenport]

There is also an active fork of rofi working on wayland support: https://github.com/lbonn/rofi

[tusqasi]

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.)

[schauveau]

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.

rofi-sway.sh.gz

[schauveau]

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.

[InfiniteCoder01]

For those who came here from google search, workaround is to pass "-normal-window" to rofi. But then it gets alignment issues

[lpanebr]

On ubuntu 22.04 I got it to work nicely with:
-normal-window -steal-focus

[axrobert]

On ubuntu 22.04 I got it to work nicely with: -normal-window -steal-focus
@lpanebr thanks a lot, broh! It's worked for me. 🙏🏻

[iax7]

On ubuntu 22.04 I got it to work nicely with: -normal-window -steal-focus

Worked also on Fedora 39!

[kinduff]

On ubuntu 22.04 I got it to work nicely with: -normal-window -steal-focus

Works on Archlinux using official package and wayland with Gnome

[abelsrzz]

rintf "aaa\nbbb\nccc\nddd\n" | rofi -dmenu

Works in Debian12 aswell

[pranay-dutta]

On ubuntu 22.04 I got it to work nicely with: -normal-window -steal-focus

how to do that?

[lpanebr]

On ubuntu 22.04 I got it to work nicely with: -normal-window -steal-focus

how to do that?

Probably in the your configuration files. Those are just two command line flags.