search

pwr-Solaar / Solaar

Linux device manager for Logitech devices
https://pwr-solaar.github.io/Solaar
GNU General Public License v2.0
5.51k stars 408 forks source link

Future of Solaar? #654

Closed FFY00 closed 3 years ago

FFY00 commented 4 years ago

I will be writing a DBus daemon to interface with Logitech devices (HID++ 1.0, HID++ 2.0, bootloader, etc.). This daemon will be written from scratch with a test suite from day 0 (using https://github.com/libratbag/ratbag-emu).

With this in mind, we should re-think the position of Solaar.

I propose that we drop all backend logic and just make Solaar a front-end for this new daemon.

Thoughts?

cc @Lekensteyn @pfps @doctor64 @drupal-daffie @MyrikLD

FFY00 commented 4 years ago

Pros:

Cons:

MyrikLD commented 4 years ago
  1. I support the separation of logic and interface, but ratbag is currently not even close ready to accept such a burden. I think, at least the project must have a stable, tested version. Btw, it still doesn't work on my computer, even with an old M325 mouse.
  2. What happened to piper? He did not cope?
  3. This sentence sounds especially funny next to this task: https://github.com/pwr-Solaar/Solaar/issues/592 So, we want to remove the stable working code of Solaar, switch to partially working ratbag and rewrite UI from scratch? This makes no sense, given that the UI for ratbag already exists.
Lekensteyn commented 4 years ago

The security benefit is important. Anyone with read access to the hidraw nodes can do keylogging and more.

As for making Solaar an UI (CLI/GUI) using the daemon as backend, that sounds reasonable. However, I would try to change the internal interfaces of Solaar to enable that, and do a gradual transition that allows use of the existing code in Solaar while the daemon is being matured, and then deprecate in the future once the daemon is ready. And then either leave the fallback backend bitrotting, or just remove it :-)

All HID-protocol related stuff would have to be moved to the daemon. From top of my head:

FFY00 commented 4 years ago

@MyrikLD I am not talking about ratbagd, this would be an entirely new daemon. libratbag is great but is vendor agnostic and so we can't implement everything the devices support. With the existence of this new daemon, libratbag would still be relevant, as it would allow device configuration integration in places such as the Gnome settings. Actually, the plan is to write the new daemon and then replace the libratbag hidpp10 and hidpp20 drivers with a new driver that would just use the new daemon.

As for making Solaar an UI (CLI/GUI) using the daemon as backend, that sounds reasonable. However, I would try to change the internal interfaces of Solaar to enable that, and do a gradual transition that allows use of the existing code in Solaar while the daemon is being matured, and then deprecate in the future once the daemon is ready. And then either leave the fallback backend bitrotting, or just remove it :-)

Hum... I think that would require a lot of work. Since we also want to re-do the UI, I think we could write the new client from scratch and provide it as an alternative in a new namespace. We would maintain the current codebase and develop the new daemon client in parallel. Once we are happy with it we would deprecate the old codebase and put the new client in the main namespace. Kinda like grub/grub-legacy, and eventually remove the old code altogether. This would make sure that users currently dependent on Solaar are not left hanging.

  • Device pairing.

  • Applying settings when a device (re-)connects. Probably best implemented in the daemon. Clients can provide the initial config and the daemon tries to make it true. Persistence can be done on either the client (advantage: works better for multi-user systems?) or daemon (advantage: would survive restarts without client interaction).

  • Device/receiver info (serial, features, etc). Cache this to avoid slowdowns?

  • Battery status notifications. This could be provided by the daemon, but many Linux systems already rely on UPower as backend, so maybe we can ignore this?

  • ...

You can add firmware updates. There's a possibility for fwupd to start using the daemon as a backend, we would just need to make sure we have a stable API. I also need better tooling for firmware updates so I really want this.

The Battery should be exported by the kernel and then picked up by UPower. 0x1000 is already working, 0x1001 should arrive in 5.6. The daemon can display battery information, but I don't think it should send desktop notifications (only DBus signals, to update the client UI).

rijnhard commented 4 years ago

Bit of a side track: I do think that packaging should play a part in this as well, flatpak for instance. As this is quite a barrier at the moment.

MyrikLD commented 4 years ago

If we are talking about creating a new demon and gradually transferring logic to it, then yes, that makes sense. I'm sorry, I didn’t understand you.

FFY00 commented 4 years ago

Bit of a side track: I do think that packaging should play a part in this as well, flatpak for instance. As this is quite a barrier at the moment.

I am not too fond of flatpak as it most of the time the wrong solution. If your distribution isn't releasing as frequently as you want then you should think about changing to a distribution that fits your needs. Solaar, particularly, is easy to release so there's no good excuse for it not to be updated that often. With this said, I am not opposed to supporting flatpak. If someone wants to step up and do it, I won't block it, I will review the changes and merge them as long as they are correctly implemented. But I have no will to do it myself, and honestly I have lots of things that could benefit more from my time.

If we are talking about creating a new demon and gradually transferring logic to it, then yes, that makes sense. I'm sorry, I didn’t understand you.

No problem, I wasn't that clear.

barolo commented 4 years ago

I am not talking about ratbagd, this would be an entirely new daemon. libratbag is great but is vendor agnostic and so we can't implement everything the devices support.

Well, Solaar is pretty device agnostic with just few generic options per device isn't it?

I have MX Master2S + Craft and the amount of options Logitech's panel [mac/win] offers is absurd. There are no plans of matching it in any way no?

FFY00 commented 4 years ago

Well, Solaar is pretty device agnostic with just few generic options per device isn't it?

No, Solaar is the opposite of agnostic. Everything is built around Logitech's protocol, and the features we provide are very Logitech specific.

I have MX Master2S + Craft and the amount of options Logitech's panel [mac/win] offers is absurd. There are no plans of matching it in any way no?

Yes, there is. This is the plan.

barolo commented 4 years ago

@FFY00 Yeah, I meant within Logitech's protocol

Yes, there is. This is the plan.

That's a nice plan, but isn't huge chunk of it implemented in software? Like per app profiles, multipurpose dials with per app functions, Duolink for keyboard+mouse combo shortucts, etc. ?

mickleby commented 4 years ago

@barolo I may be on the wrong track, lemme know. "isn't huge chunk of it implemented in software? Like per app profiles, multipurpose dials with per app functions, Duolink for keyboard+mouse combo shortucts, etc." Ideally we can introspect device functionality, thereby eliminating all this per-case-basis code.

barolo commented 4 years ago

@mickleby What I was saying is that huge part of functionality of recent Logi devices is bound to their control centre not the device itself. There are cases like Duolink which could benefit multiple devices and edge cases like touch "dial" on Craft which has its own frickin sdk. On mac/win it's hugely useful [ eg. in graphic apps its functions switch depending on the tool being used ] while on linux it serves as volume knob...

FFY00 commented 4 years ago

@mickleby What I was saying is that huge part of functionality of recent Logi devices is bound to their control centre not the device itself. There are cases like Duolink which could benefit multiple devices and edge cases like touch "dial" on Craft which has its own frickin sdk. On mac/win it's hugely useful [ eg. in graphic apps its functions switch depending on the tool being used ] while on linux it serves as volume knob...

If the functionality depends on the device in some way, we could implement it. For example, the dial on the Craft, IIRC it adds functionality that is not available over the standard HID protocol.

barolo commented 4 years ago

@mickleby What I was saying is that huge part of functionality of recent Logi devices is bound to their control centre not the device itself. There are cases like Duolink which could benefit multiple devices and edge cases like touch "dial" on Craft which has its own frickin sdk. On mac/win it's hugely useful [ eg. in graphic apps its functions switch depending on the tool being used ] while on linux it serves as volume knob...

If the functionality depends on the device in some way, we could implement it. For example, the dial on the Craft, IIRC it adds functionality that is not available over the standard HID protocol.

Wouldn't that require writing in plugin support for apps, some kind of api? like Logitech's Control does? It has per app plugins/profiles for Craft's dial.

mickleby commented 4 years ago

@mickleby What I was saying is that huge part of functionality of recent Logi devices is bound to their control centre not the device itself. There are cases like Duolink which could benefit multiple devices and edge cases like touch "dial" on Craft which has its own frickin sdk. On mac/win it's hugely useful [ eg. in graphic apps its functions switch depending on the tool being used ] while on linux it serves as volume knob...

If the functionality depends on the device in some way, we could implement it. For example, the dial on the Craft, IIRC it adds functionality that is not available over the standard HID protocol.

Wouldn't that require writing in plugin support for apps, some kind of api? like Logitech's Control does? It has per app plugins/profiles for Craft's dial.

Not having a Craft or any need for Options or Duolink, I'm unclear how this discussion relates to solaar. Sounds like you are discussing implementing Logitech apps in solaar. Do you view solaar as an umbrella project that implements each new generation of Logitech apps? If this, how do you envision legacy support when Logitech moves on?

A quick read about Duolink, and I do not see the connection to solaar. Doesn't Duolink intercept and modify input signals from devices? Spitballing, I would implement Duolink before the receiver sends the scancode/keycode, perhaps at the HID I/O transport driver level (https://www.kernel.org/doc/html/latest/hid/hid-transport.html). (This also seems relevant https://lwn.net/Articles/614233/) (And this REALLY sounds relevant https://patchwork.kernel.org/patch/10878405/) Do I misunderstand Duolink?

FFY00 commented 4 years ago

I started working on it.

In case anyone is interested: https://github.com/FFY00/logitechd

barolo commented 4 years ago

@mickleby What I was saying is that huge part of functionality of recent Logi devices is bound to their control centre not the device itself. There are cases like Duolink which could benefit multiple devices and edge cases like touch "dial" on Craft which has its own frickin sdk. On mac/win it's hugely useful [ eg. in graphic apps its functions switch depending on the tool being used ] while on linux it serves as volume knob...

If the functionality depends on the device in some way, we could implement it. For example, the dial on the Craft, IIRC it adds functionality that is not available over the standard HID protocol.

Wouldn't that require writing in plugin support for apps, some kind of api? like Logitech's Control does? It has per app plugins/profiles for Craft's dial.

Not having a Craft or any need for Options or Duolink, I'm unclear how this discussion relates to solaar. Sounds like you are discussing implementing Logitech apps in solaar. Do you view solaar as an umbrella project that implements each new generation of Logitech apps? If this, how do you envision legacy support when Logitech moves on?

A quick r`ead about Duolink, and I do not see the connection to solaar. Doesn't Duolink intercept and modify input signals from devices? Spitballing, I would implement Duolink before the receiver sends the scancode/keycode, perhaps at the HID I/O transport driver level (https://www.kernel.org/doc/html/latest/hid/hid-transport.html). (This also seems relevant https://lwn.net/Articles/614233/) (And this REALLY sounds relevant https://patchwork.kernel.org/patch/10878405/) Do I misunderstand Duolink?

@mickleby My focus is not on software but the functionality/control it provides over device. I'm focusing strictly on Control Centre which in part is analogous to Solaar's gui no? On the surface it provides various controls over device's functionality, just in way more extensive manner. Craft is a special case where removing features provided by CC also removes the main selling point of the Craft [ It might be easier to think of Craft's knob as separate multi-function device, moving it under Linux removes 99% of its functionality ]

FFY00 commented 4 years ago

Progress update: The hardest part in my opinion, the backend, has been done. I had to implement ioctl(s) to be able to query the kernel for the report descriptor of hidraw nodes. The next step is filtering the devices based on their report descriptors and then starting implementing the HID++ 1.0 protocol for the receivers.

https://github.com/FFY00/logitechd/blob/master/logitechd/hidraw.py

FFY00 commented 4 years ago

Basic HID parser done and filtering working :grin:. Now let's start to implement the protocol.

FFY00 commented 4 years ago

Okay, so I am at a point now where I would like to receive some feedback.

Please have a look at the code and tell me what you think. Feel free to ask me about anything that you don't understand.

https://github.com/FFY00/logitechd

cc @pfps @Lekensteyn

Lekensteyn commented 4 years ago

@FFY00 Some suggestions:

A question, why do you have to query the report descriptor?

FFY00 commented 4 years ago

device.py: use logging instead of print

Yes, I will. I am just using print in this initial stage, I will replace everything with logging soon.

device.py: can hidraw actually return multiple reports at a time? Based on kernel.org/doc/html/latest/hid/hidraw.html#read, I would expect only one queued report.

Yes, it will. From the documentation I would expect that too, but I did in fact receive multiple reports at a time.

hidraw.py: using time.time() for timeout handling will not work when the time changes, or when the system sleeps. Try a monotonic clock source instead.

Didn't think about that :grin:, will do.

A question, why do you have to query the report descriptor?

Physical devices usually export several endpoints: for mouse data, keyboard data, vendor data, etc. We need to be able to distinguish them apart. The way we tell them apart is by looking at the HID descriptor and seeing if it includes a vendor data page, which means that the device supports vendor protocol.

What Solaar does is that it will search for the endpoint owned by the hid-logitch-dj kernel driver. This works for wireless devices but not for wired devices, as these are not claimed by hid-logitech-dj.

Having the HID report available is also useful for other things. For example, when most Logitech devices are connected via Bluetooth they don't support short (0x10) reports. Using the report descriptor we can see which report IDs the device supports.

We do that in libratbag: https://github.com/libratbag/libratbag/commit/26c534cc742dfdbb14a889287f7771063be834cc

PixlOne commented 4 years ago

Sorry for the late comment, I only just found this thread.

I've been working on a Logitech configuration daemon for almost a year now called logiops in C++. Perhaps that could be of use in this idea?

After I successfully test and refine the reworked version on the refactor branch and finish the DBus interface, I'm thinking that we could perhaps use it in this idea? I was originally planning to write my own GUI but I also want to interface with libratbag.

I'm open to any suggestions or ideas on meshing this idea of having a Logitech daemon as a backend with my project.

FFY00 commented 4 years ago

Sure, that would be great. The initial work is at https://github.com/FFY00/logitechd, please see https://github.com/FFY00/logitechd/issues/2.

I really need to get around and add the DBus stuff.

PixlOne commented 4 years ago

Update on my project, I've finished the refactor and I've been working on implementing DBus support on the ipc branch.

Here's what I have so far:

Let me know if you have any suggestions or comments about the project. Also, if someone who is familiar with libratbag's code has any ideas on making the project more compatible with libratag, please tell me.

WhyNotHugo commented 3 years ago

I'm using an MX Vertical vie bluetooth, and blueman reports the battery at 100%. This is because the mouse reports battery at 100% via the bluetooth API, but reports the right level via the logitech API.

I wonder if some of the functionality solaar provides could somehow end up in bluez, so that the usual bluetooth API returns the right battery level. The goal here is that the usual bluetooth tools (blueman, gnome's bluetooth thing, kde's bluetooth app, etc) can all report the right battery level for devices.

This would be really helpful since I already use blueman to handle most bluetooth devices, and it reports battery level for those. Having it report the right battery level for bluetooth mice would be super (again, this also applies to other userspace bluetooth device managers).

FFY00 commented 3 years ago

@WhyNotHugo that should probably get a quirk in the kernel then, especially since the hid-logitech-hidpp driver should be able to get the correct information.

Could you send an email to the kernel mailing lists? linux-input@vger.kernel.org linux-bluetooth@vger.kernel.org

I have a MX Vertical so I should be able to write the patch for this if needed, it might just take some time until I am able to work on that.

reply-nick commented 3 years ago

Add Wayland support for gestures.

LeoniePhiline commented 3 years ago

@FFY00 I just started with a MX Vertical and an K860 keyboard, and I am SO glad how amazingly well everything is working with linux (openSUSE KDE). Thank you and all the contributors so much for your work on the software!

pfps commented 3 years ago

Thanks for your kind words