Skip to content

libinput: bump lua54 to lua55 - #62075

Open
b-r-y wants to merge 1 commit into
void-linux:masterfrom
b-r-y:libinput-update
Open

libinput: bump lua54 to lua55#62075
b-r-y wants to merge 1 commit into
void-linux:masterfrom
b-r-y:libinput-update

Conversation

@b-r-y

@b-r-y b-r-y commented Aug 17, 2026

Copy link
Copy Markdown

Testing the changes

  • I tested the changes in this PR: YES

Local build testing

  • I built this PR locally for my native architecture, (x86-glibc)
  • I built this PR locally for these architectures (if supported. mark crossbuilds):
    • x86-musl

Reasons and the bug this fixes

The motivation is compilation of latest hyprland for Void. Moving to aquamarine 0.14 and hyprland 0.56.2 exposed an issue in libinput when it is compiled against lua54 and the application (in this case hyprland/aquamarine) compiled against lua55. The symbols exposed by libinput are not lua versioned so lua_getfield, for example is the same no matter lua54 or lua55. This leads to a crash and incompatibility. While it is hyprland exposing this at the moment, i think this will be true for any application built against lua55 trying to use libinput unless updated. Recent introduction of lua55 to void-packages makes this update trivial.

Thanks for the consideration.

@Duncaen

Duncaen commented Aug 17, 2026

Copy link
Copy Markdown
Member

We do not support hyprland, lua55 was just merged a day or two ago, nothing else depends on it or provides modules for 5.5 yet either.

@b-r-y

b-r-y commented Aug 17, 2026

Copy link
Copy Markdown
Author

Yes i understand hyprland is not supported. The case i make is that anything built with lua55-devel will crash out if it also uses libinput without this update - hyprland simply exposes the issue.

@Duncaen

Duncaen commented Aug 17, 2026

Copy link
Copy Markdown
Member

And anything with libinput and lua5.4 that is in the official repositories will crash if this PR was to be merged.

@b-r-y

b-r-y commented Aug 17, 2026

Copy link
Copy Markdown
Author

isn't this actually about libinput rather than lua? I mean if anything is to crash due to libinput being compiled with lua55 instead of lua54, would it not be things that depend on libinput rather than lua54?

I am not too much into the details but i think lua55 provides backwards compatibility for the symbols it exposes.

From what i can see these would be in danger right?:
xbps-query -XR libinput
SwayOSD-0.3.0_1
Waybar-0.15.0_3
cagebreak-3.2.1_1
clutter-1.26.4_1
efl-1.28.1_2
gamescope-3.16.20_1
ironbar-0.19.0_1
kodi-21.2_5
kwin-6.7.4_1
labwc-0.20.1_1
libinput-debug-gui-1.31.3_1
libinput-devel-1.31.3_1
libinput-gestures-2.81_1
magpie-0.9.4_1
mangowc-0.14.4_1
muffin-6.6.3_1
mutter-48.7_1
niri-26.04_1
qt5-gui-5.15.11+20231124_6
qt6-gui-6.11.1_1
qtile-wayland-0.37.0_1
river-0.3.7_1
sway-1.12_1
swayfx-0.5.3_2
touchegg-2.0.17_2
way-displays-1.14.0_3
wayfire-0.10.1_1
weston-15.0.1_1
wlroots0.18-0.18.3_1
wlroots0.19-0.19.3_1
wlroots0.20-0.20.2_1
xf86-input-libinput-1.5.0_1

Of them i have installed these and they run (granted only few days up until now):
xbps-query -X libinput
niri-26.04_1
qt6-gui-6.11.1_1
wlroots0.20-0.20.2_1
xf86-input-libinput-1.5.0_1

@Duncaen

Duncaen commented Aug 17, 2026

Copy link
Copy Markdown
Member

As far as I understand the issue would be two abi incompatible lua versions loaded into the same process with conflicting symbols.

% ldd /usr/bin/weston|grep libinput    
        libinput.so.10 => /usr/lib/libinput.so.10 (0x00007f498e776000)
% ldd /usr/lib/weston/lua-shell.so|grep lua
        liblua5.4.so.5.4 => /usr/lib/liblua5.4.so.5.4 (0x00007fd8c2bad000)

@b-r-y

b-r-y commented Aug 17, 2026

Copy link
Copy Markdown
Author

I think your example is correct. But i think i was trying to argue that from what i can see compiling libinput.so.10 with lua55 does not prevent it from answering lua54 calls fine because the symbols are the same:

nm -D /usr/lib/libinput.so.10 | grep -E 'lua_|luaL_'
U luaL_argerror
U luaL_checkinteger
U luaL_checklstring
U luaL_checktype
U luaL_checkudata
U luaL_error
U luaL_loadfilex
U luaL_newmetatable
U luaL_newstate
U luaL_ref
U luaL_requiref
U luaL_setfuncs
U luaL_traceback
U luaL_unref
U lua_close
U lua_createtable
U lua_getfield
U lua_gettable
U lua_gettop
U lua_isnumber
U lua_newuserdatauv
U lua_next
U lua_pcallk
U lua_pushboolean
U lua_pushinteger
U lua_pushlightuserdata
U lua_pushnil
U lua_pushstring
U lua_pushvalue
U lua_rawgeti
U lua_rawseti
U lua_setfield
U lua_sethook
U lua_setmetatable
U lua_settable
U lua_settop
U lua_setupvalue
U lua_tolstring
U lua_touserdata
U lua_type
U lua_typename

But then there is this as well so what do i know... https://www.lua.org/manual/5.5/manual.html#8

How can i proceed? Do i need test all packages depending on libinput when rebuild against lua55? What is the protocol for such cases?

@b-r-y

b-r-y commented Aug 17, 2026

Copy link
Copy Markdown
Author

it seems like only this weston package includes both lua54 and libinput and the two runtimes can collide. Eveything else includes only lua54 or only libinput...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants