output-rotation, mouse-selection, gyro-sensor support, kmscon.conf manpage

[MacSlow]

This is the whole bunch of all the features I added to kmscon (now based on aetf's 'develop' branch). It is output-rotation support, mouse selection/cut/paste support, gyro-sensor support and finally an additional man-page, which documents the configuration-file 'kmscon.conf'.

Each feature/patch also exists as a single branch (building on top of each other), if you prefer smaller chunks. I am trying to make this as easy for review and testing as possible.

[takase1121]

Hi, I've been trying to use this patch in conjunction with #71, it seems that kmscon_mouse.c requires linking to libm (fmod), which isn't done in meson.build and src/meson.build. I kept on getting linking errors without doing that.

[MacSlow]

I see... I will look into it this afternoon. Best regards... MacSlow Takase ***@***.***> schrieb am Sa., 7. Okt. 2023, 05:37:

…

Hi, I've been trying to use this patch in conjunction with #71 <#71>, it seems that kmscon_mouse.c requires linking to libm (fmod), which isn't done in meson.build and src/meson.build. I kept on getting linking errors without doing that. — Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACWFRKSVEE2CGGX5RPWTK73X6DFA3AVCNFSM6AAAAAA2VVVRQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJRGU4DKNZQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[MacSlow]

Hi, I've been trying to use this patch in conjunction with #71, it seems that kmscon_mouse.c requires linking to libm (fmod), which isn't done in meson.build and src/meson.build. I kept on getting linking errors without doing that.

I looked at this again on a different machine and cannot reproduce the linking issue with regards to libm. I locally merged skyvine's desired-width/height branch with my PR and do not get any linking issues. I used an Ubuntu 22.04.3 LTS machine with the usual build-essential packages.

Do you perhaps still have a log-file of the failing compile/linking step?

[obrmao]

@MacSlow Since I seem to have similar issues let me paste my output:

==> Starting build()...
+ exec meson setup --prefix /usr --libexecdir lib --sbindir bin --buildtype plain --auto-features enabled --wrap-mode nodownload -D b_lto=false -D b_pie=true -D python.bytecompile=1 /home/alarm/kmscon-g/src/kmscon builddir/ -Dtests=false
Directory already configured.

Just run your build command (e.g. ninja) and Meson will regenerate as necessary.
If ninja fails, run "ninja reconfigure" or "meson setup --reconfigure"
to force Meson to regenerate.

If build failures persist, run "meson setup --wipe" to rebuild from scratch
using the same options as passed when configuring the build.
To change option values, run "meson configure" instead.
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/alarm/kmscon-g/src/builddir
ninja: Entering directory `/home/alarm/kmscon-g/src/builddir'
[1/9] Generating src/shl_githead.c with a custom command
fatal: No names found, cannot describe anything.
[2/2] Linking target src/kmscon
FAILED: src/kmscon
cc  -o src/kmscon src/kmscon.p/pty.c.o src/kmscon.p/font.c.o src/kmscon.p/font_8x16.c.o src/kmscon.p/text.c.o src/kmscon.p/text_bblit.c.o src/kmscon.p/kmscon_module.c.o src/kmscon.p/kmscon_seat.c.o src/kmscon.p/kmscon_conf.c.o src/kmscon.p/kmscon_main.c.o src/kmscon.p/kmscon_mouse.c.o src/kmscon.p/kmscon_dummy.c.o src/kmscon.p/kmscon_terminal.c.o -Wl,--as-needed -Wl,--no-undefined -Wl,-export-dynamic -pie -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -march=armv8-a -O2 -pipe -fstack-protector-strong -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -Wl,--start-group src/libconf.a src/libshl.a external/libext-htable.a src/libeloop.a src/libuterm.a /usr/lib/libxkbcommon.so /usr/lib/libtsm.so -pthread /usr/lib/libdbus-1.so /usr/lib/libGLESv2.so /usr/lib/libudev.so /usr/lib/libsystemd.so /usr/lib/libdrm.so /usr/lib/libEGL.so /usr/lib/libgbm.so -Wl,--end-group
/usr/bin/ld: src/kmscon.p/kmscon_mouse.c.o: undefined reference to symbol 'fmodf@@GLIBC_2.17'
/usr/bin/ld: /usr/lib/libm.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().
    Aborting...

[obrmao]

What worked for me is to add:

link_args: ['-lm'],

in src/meson.build as such:

kmscon = executable('kmscon', kmscon_srcs,
  dependencies: [xkbcommon_deps, libtsm_deps, threads_deps, dbus_deps, dl_deps, conf_deps, shl_deps, eloop_deps, uterm_deps],
  export_dynamic: true,
  install: true,
  link_args: ['-lm'],
  install_dir: libexecdir,
)

[takase1121]

What worked for me is to add:

link_args: ['-lm'],

in src/meson.build as such:

kmscon = executable('kmscon', kmscon_srcs,
  dependencies: [xkbcommon_deps, libtsm_deps, threads_deps, dbus_deps, dl_deps, conf_deps, shl_deps, eloop_deps, uterm_deps],
  export_dynamic: true,
  install: true,
  link_args: ['-lm'],
  install_dir: libexecdir,
)

This is not the correct way to fix it, the correct way is to use compiler.find_library('m') and add it as a dependency.

[obrmao]

Thanks @takase1121!

That worked as well, at top:

cc = meson.get_compiler('c')
mlib = cc.find_library('m')

and then:

kmscon = executable('kmscon', kmscon_srcs,
  dependencies: [mlib, xkbcommon_deps, libtsm_deps, threads_deps, dbus_deps, dl_deps, conf_deps, shl_deps, eloop_deps, uterm_deps],
  export_dynamic: true,
  install: true,
  install_dir: libexecdir,
)

[MacSlow]

Greetings takase1121 & obrmao!

I added your suggestions to my branches hoping it will avoid other people running into the same issue. Still, I could not reproduce the stated problem on my systems (ubuntu 22.04 and debian 12). But adding that explicit library-dependency does not hurt :)

[Aetf]

Thank you so much for the PR ! @MacSlow unfortunately I don't have much time review such a large one nowadays. I'd appreciate it if you could reduce it into several smaller ones like you suggested. 🙏

[MacSlow]

Thank you so much for the PR ! @MacSlow unfortunately I don't have much time review such a large one nowadays. I'd appreciate it if you could reduce it into several smaller ones like you suggested. 🙏

Oh... hey Aetf! :)

How small are we talking?

Are the four PR, which build upon each other, still too large? I could try so see how much further I could slice and dice them. That will not happen in the next few days - load from work is a bit intense at the moment... took me some time to reply here, right :) - but I gladly do whatever is needed to move stuff 'upstream' and avoid forking!

Best regards...

MacSlow

[Aetf]

Thanks. Was looking at the all commits page. Your commit messages look reasonable (appreciate that!). I'll give it a try. Can't promise anything though. Same with work here - I have much less time than I would like to spend on OSS :-p

[hustlerone]

oh hey you're back

hopefully we get gpm into kmscon

[kdj0c]

I know it's very late, but I've taken a look at this PR.
It can be rebased easily on top of main.

Mouse support:

• It should use the eloop API, waiting for data instead of polling with a timer. (I can probably fix that).
• Using /dev/input/mice is simple, but doesn't work well when using a Virtual Machine (the coordinates are absolute in this case) so you can move the pointer only on a tiny region, which makes it unusable. The alternative is to use /dev/input/eventX, but this is more complex, so you might as well use libinput.
• The pointer is only visible when using the gltex renderer, but I've hacked something with the bbulk renderer too.
• There should be an option to disable mouse support if not needed.

Rotation:

• Also only works with gl renderer, shouldn't be that hard to implement other renderer.
• There a few code duplication

Man page:

• That's cool, as there is no sample of a good kmscon.conf.

If you don't mind, I will split this in 3 PR. I think the man page can be merged quickly, the two others need more refinement.

[kdj0c]

Regarding rotation, there is also a drm property, so that the rotation is done in hardware:
https://drmdb.emersion.fr/properties/4008636142/rotation
But it has the drawback that it's not supported by all drivers. (but at least i915/xe, amdgpu and nvidia-drm supports it).

[MacSlow]

Regarding rotation, there is also a drm property, so that the rotation is done in hardware: https://drmdb.emersion.fr/properties/4008636142/rotation But it has the drawback that it's not supported by all drivers. (but at least i915/xe, amdgpu and nvidia-drm supports it).

Interesting... while initially searching for that, nothing like that was shown in search-results :)

[kdj0c]

@MacSlow I've rebased and reworked a bit your rotation patches, and added support for the pixman renderer. I'll submit another PR when I've also the bbulk renderer support.

I didn't use the drm properties, because there is no support in virtual drivers, so it's more difficult to test.

[MacSlow]

@MacSlow I've rebased and reworked a bit your rotation patches, and added support for the pixman renderer. I'll submit another PR when I've also the bbulk renderer support.

Oh, very nice!

I didn't use the drm properties, because there is no support in virtual drivers, so it's more difficult to test.

Yeah, I was not aware of those even existing.

[kdj0c]

I've started to look at mouse support.
I had to rewrite it, as I wanted it to be an extension of the keyboard support with the uterm_input.
so basically adding mouse to struct uterm_input_dev, and no longer rejecting non-keyboard device.

This allows to work with the seat support (so it should be possible to specify which mouse to connect to which seat, along with keyboards).
Also uevent will allow to properly support touchscreen, and virtual mouse.

I will send a PR when it's ready.

[howl]

For output-rotation and gyro-sensors take into account panel orientation quirks for some devices with non-standard oriented panels. I think gyro transformation matrix in udev is not necessary to take into account.

This issues I think that should be achieved in a general way for linux because for example mutter takes them into account but actually kwin is not aware and is needed to be coded per graphical program that manages the output but is out of scope.