efernau / rot8 Goto Github PK

Hi,

rot8 is working for me, when I try it manually from the terminal. Now I want to add it to my startup, so it will be running in the background after I log into sway.

I have a working sway config and I am just adding these lines for rot8:

# autorotate
exec swaymsg "input 1386:21173:Wacom_HID_52B5_Finger map_to_output eDP-1"
exec rot8

The swaymsg from that codeblock is being executed. (If I run rot8 manually, then the touchscreen will be mapped correctly).
However rot8 is not being started. When I check my list of processes, rot8 is not there.

Any ideas? Let me know if you have a suggestion on how I can debug my sway startup.

there is an arch and void package , i like both. thanks!
guix is probably in the work.
what about alpine, nixos, debian, ubuntu. and others.
contribution is welcome.

Rotating the touchscreen so it's flipped but the touch inputs are not inverted. This is on sway (wayland)

Distribution: Fedora 36
WM: Sway
Problem: it does not work
RUST_BACKTRACE=full rot8 output:

thread 'main' panicked at 'Unable to deserialize swaymsg JSON output: Error("missing field `transform`", line: 296, column: 3)', src/main.rs:72:18
stack backtrace:
   0:     0x5611b5279a1c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h572300f0ebfde2a7
   1:     0x5611b529dd5c - core::fmt::write::h9a40954895def713
   2:     0x5611b5275ab1 - std::io::Write::write_fmt::h589135a83419f2d6
   3:     0x5611b527b245 - std::panicking::default_hook::{{closure}}::h619386df4f38a529
   4:     0x5611b527af04 - std::panicking::default_hook::ha87f40e82c315143
   5:     0x5611b527b978 - std::panicking::rust_panic_with_hook::h220e25558f92196d
   6:     0x5611b527b687 - std::panicking::begin_panic_handler::{{closure}}::hffd3696cd0a1a22a
   7:     0x5611b5279eb4 - std::sys_common::backtrace::__rust_end_short_backtrace::hbec50169ea271f2f
   8:     0x5611b527b3a9 - rust_begin_unwind
   9:     0x5611b5178313 - core::panicking::panic_fmt::h5f7f26e7daf91179
  10:     0x5611b5178403 - core::result::unwrap_failed::h8978d5eaf6c8d94c
  11:     0x5611b5184703 - rot8::main::h1c87f8fb115403d5
  12:     0x5611b517da56 - std::sys_common::backtrace::__rust_begin_short_backtrace::hb7cd74be5b415e46
  13:     0x5611b517ebc2 - std::rt::lang_start::{{closure}}::h93dc38bfd0ba8474
  14:     0x5611b52791ce - std::rt::lang_start_internal::hf89834035bdbd4c6
  15:     0x5611b51864e2 - main
  16:     0x7f15518f4550 - __libc_start_call_main
  17:     0x7f15518f4609 - __libc_start_main_impl
  18:     0x5611b5178b45 - _start
  19:                0x0 - <unknown>  

The tilt threshold which triggers a screen rotation seems to be hard-coded in (checking if axes are over 500000). It would be nice to have this as a command line option. It would also be nice to have a more complex algorithm which rotates easier than it un-rotates (i.e. asymmetrical thresholds).

https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-output-management-unstable-v1.xml

Hi, i want to use rot8, but I get the following error:
Error: "Failed to get current display rotation"
I'm using sway. If there is any more relevant detail to my, please let me know.

Generally speaking, I don't think I'm the first one to ever run into this issue and some guidlines on troubleshooting it would be nice.

So I recently got a PineTab, which is an ARM tablet with a detachable keyboard dock (see picture, the magnetic connector is actually USB). It has the following quirks:

The native orientation is rotated by 90 degrees

(Yes, that's the native resolution - 800x1280)

Because we use the normal orientation to decide whether to enable the keyboard, we need to

• a) allow the user to specify "the orientation at which the keyboard is disabled" - easy but confusing ("why is my normal not 'normal'?"), or
• b) allow the user to specify a rotation applied to the vector before deciding the orientation - less confusing

Actually, as the keyboard can be detached, we should have a feature where we lock the rotation to the normal human orientation when an input device is present (in this case, the USB keyboard).

Edit: Wanted to set up everything again half a year later, and saw this silliness. Please, ignore my brain fart 😆 There is no need to normalize anything, or flip the axes. In fact, the current code in src/main.rs is over-complicating the thing by comparing the vectors.

Hi there, it looks like the strip Cargo feature was enabled, but this is causing some build time errors since that feature is only available on nightly, and is gated even there. When I compile with the --release flag on Cargo 1.58.0, with nightly enabled, I get the following:

$ RUSTUP_TOOLCHAIN=nightly cargo build --frozen --release --all-features
error: failed to parse manifest at `/home/mnussbaum/src/rot8/Cargo.toml`

Caused by:
  feature `strip` is required

  The package requires the Cargo feature called `strip`, but that feature is not stabilized in this version of Cargo (1.58.0-nightly (ad50d0d26 2021-11-17)).
  Consider adding `cargo-features = ["strip"]` to the top of Cargo.toml (above the [package] table) to tell Cargo you are opting in to use this unstable feature.
  See https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#profile-strip-option for more information about the status of this feature.

I am trying to package rot8 for GNU Guix and have a package definition working for it, but I am having trouble checking whether it works as expected or not. Whenever I execute the built binary with ./rot8 --display DSI-1, my screen rotates sideways and then won't rotate again even if I move it.

Would that be a sign that it fails to read accelerometer data, or my accelerometer is not working correcty (maybe I'm missing dependencies)? I vaguely remember I once read accelerometer data from some command in the terminal and could confirm the values were changing depending on the position of my screen, but I can't remember what was the command to confirm that now.

Also, my machine is a small UMPC and often those come with a screen that is actually recognized as a portrait screen by default. I work around this using the transform function of sway or wlr-randr, but seeing that rot8 automatically rotates my screen to portrait mode makes me think the accelerometer data are not corrected accordingly. Is there a way to set an offset in rot8 so that it rotates from a reference (i.e., force a 90-degree rotation before applying its own rotation based on sensor data)?

For instance, on my system (NixOS), the binary is called X and I need this patch to make this tool work:

diff --git a/src/main.rs b/src/main.rs
index 89724de..688faf2 100644
--- a/src/main.rs
+++ b/src/main.rs
@@ -138,7 +138,7 @@ fn main() -> Result<(), String> {
         >= 1
     {
         Backend::Sway
-    } else if String::from_utf8(Command::new("pidof").arg("Xorg").output().unwrap().stdout)
+    } else if String::from_utf8(Command::new("pidof").arg("X").output().unwrap().stdout)
         .unwrap()
         .len()
         >= 1

I am using a (Pinephone Pro)[https://pine64.com/product/pinephone-pro-explorer-edition/] and when in landscape mode it seems to notice just fine the orientation but in portrait mode it is wrong by 180 degrees. I am using sway and installed rot8-git through AUR. Any ideas where to even troubleshoot this?

I am using rot8 on Lenovo ThinkPad X1 Yoga 4th Gen with Arch Linux and aur/sway-git-wlroots-git. When I execute rot8, everything works fine, but when I call rot8 --oneshot, it quits and does nothing (when it should, obviously:)).

Thanks for the amazing utility, by the way!

I'm using sway and I'm not able to get this to work

Which input am I supposed to map to which output? Is it the accelerometer to the display? or touchpad to the display?

If I call 'rot8 --display DSI-1' it also does not appear to work.

Hi,
thanks for awesome crate. However, I ran it on my desktop machine with GDM running under X11 and I got panic. Seems there are some unwrap calls when querying the backend.

FYI I'm packaging this crate for Guix.

$ RUST_BACKTRACE=1 /gnu/store/rwbscw79gmc5bn1zdxxkwjszfpgzmqsh-rust-rot8-0.1.3/bin/rot8 
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }', src/main.rs:134:40
stack backtrace:
   0: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
   1: core::fmt::write
   2: std::io::Write::write_fmt
   3: std::panicking::default_hook::{{closure}}
   4: std::panicking::default_hook
   5: std::panicking::rust_panic_with_hook
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::result::unwrap_failed
   9: rot8::main
  10: std::rt::lang_start::{{closure}}
  11: std::rt::lang_start_internal
  12: main
  13: __libc_start_main
  14: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Hi there, just opening and then closing this issue to let you know I've made an AUR package for your project - https://aur.archlinux.org/packages/rot8-git. I'm happy to turn it over to you if you want to maintain it, otherwise I'm happy to keep it up-to-date.

Thanks for the nice tool!

I just installed rot8 through the rot8-git AUR package. Upon trying rot8 --touchscreen "ELAN9008:00 04F3:2C82", it hangs and never finishes it doesn't rotate the screen (I misunderstood). Is there something I'm missing?

Opening this issue to get feedback, how would you feel about adding a way to configure custom commands to run after a screen rotation event?

My use case is that I need to restart waybar after rotation for it to resize to fit the new output dimensions. I could write a custom script to watch the accelerometer status but it feels like it would be very duplicative of the logic already defined in this project.

I think my ideal would be to add an optional config file that would include a list of commands to execute after a rotation event is detected. What do you think?

I tried to use rot8 on a Surface 3 which has a screen shown as DSI-1, instead of the default eDP1.

Using -d DSI-1 doesn't seem to do anything. Just in case, I tried as root, but still no luck.
On another tablet, non surface and with eDP1 screen, rot8 works perfectly, so I'm hoping to get the same experience with the surface :)

Is there a way to debug or get logs?

Rotation from gdm or in gnome, without rot8, works properly so I guess the sensors are fine.

I noticed this trying to adjust touch gestures with lisgd. I thought it was an issue until I ran lisgd &, and then it worked flawlessly.
In my opinion it could be easier if it's specified that long run commands blocks new rotation request

I'm using rot8 under X calling it at startup with the following command
rot8 --touchscreen 'WACF3200:00 29BD:1102'

When I rotate the device, the screen and the touch screen are correctly rotated, but the stylus is not.

This is the output of xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ VEN_0488:00 0488:1038 Mouse id=12 [slave pointer (2)]
⎜ ↳ VEN_0488:00 0488:1038 Touchpad id=13 [slave pointer (2)]
⎜ ↳ PS/2 Generic Mouse id=20 [slave pointer (2)]
⎜ ↳ WACF3200:00 29BD:1102 Stylus Pen (0xc025a28c) id=21 [slave pointer (2)]
⎜ ↳ WACF3200:00 29BD:1102 Stylus Eraser (0xc025a28c) id=22 [slave pointer (2)]
⎜ ↳ WACF3200:00 29BD:1102 id=9 [slave pointer (2)]
⎜ ↳ WACF3200:00 29BD:1102 UNKNOWN id=11 [slave pointer (2)]
⎜ ↳ WACF3200:00 29BD:1102 Stylus Pen (0xc0000000) id=23 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Video Bus id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ Sleep Button id=8 [slave keyboard (3)]
↳ WACF3200:00 29BD:1102 Stylus id=10 [slave keyboard (3)]
↳ sof-soundwire Headset Jack id=14 [slave keyboard (3)]
↳ Intel HID events id=15 [slave keyboard (3)]
↳ Intel HID 5 button array id=16 [slave keyboard (3)]
↳ Dell Privacy Driver id=17 [slave keyboard (3)]
↳ Dell WMI hotkeys id=18 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=19 [slave keyboard (3)]

How can I have also the stylus rotated?

On my Surface Pro 6 the stylus/pen and touchscreen are 2 separate inputs. However, rot8 only allows one input to be passed for Xorg.

It works on Sway correctly because you can pass input <DeviceID> map_to_output <Display> twice in your Sway config.