search

jahnf / Projecteur

Linux Desktop Application for the Logitech Spotlight device (and similar devices) - Digital Laser Pointer
MIT License
379 stars 33 forks source link

Feature Request: Spotlight overlay fade in/out #76

Closed jahnf closed 4 years ago

jahnf commented 4 years ago

It would be nice if the spot light overlay could fade in and fade out to have an overall smoother experience.

jahnf commented 4 years ago

@fmuelle4711 @gyps @maehne @frigaut @giswqs @mayanksuman @rkerschn I tested another way of handling the overlay window, which would allow a fade in and fade out effect (and other effects) when showing the spotlight.

It works for me on GNOME and in a KDE virtualbox with multiple screens. If you have some time, it would be great if you could test it on your (multi-screen) systems Edit: Now on develop

Thank you in advance

mayanksuman commented 4 years ago

Hi,

The code in Spotlight::scanForDevices assumes one input device per hid device entry, that is not guaranteed. Please checkout my folder listing for hid devices path (attached file: hid_folder.txt). A device entry can have multiple inputs.

As a result, my mouse input was not being taken by Projecteur out of box.

jahnf commented 4 years ago

Hi Mayank, which device are you talking about in your attached file?

mayanksuman commented 4 years ago

Hi Mayank, which device are you talking about in your attached file?

PLease check /sys/bus/hid/devices/0003:046D:C53E.0003 on line 44 onwards in attached files. It has three input devices input28, input29 and input30 with their associated event files.

jahnf commented 4 years ago

Ah yes alright, thanks for the input - the Linux versions I use seem to put handle that differently - needs to be fixed indeed.

jahnf commented 4 years ago

Thanks mayank, I fixed the issue you noticed. Could you please give it a try with the last change? Thank you very much.

Edit: but also I saw a lot of code that I like to refactor when going through that method again :smile:

mayanksuman commented 4 years ago

The problem is fixed now. However, I noticed that all inputs are taken of Event type no Hidraw on my system.

Digging into the problem, I have found one event device event24 not connected to logitech-spotlight by id (see attached file spotlight_input_devices.txt).

In the file hidraw tree structure show event21 to event24 linked to logitech spotlight, but in /dev/input/by-id all but event24 do not exist. Is this the Hidraw device?

mayanksuman commented 4 years ago

https://github.com/jahnf/Projecteur/blob/8cb1bd88c546016c650b97f2bf72b94588460517/src/spotlight.cc#L687 Further I do not think this line will ever going to execute. This line and associated if statement can be removed given that we have already tested the vendorID and productID for the parent hid folder uevent file in L648.

jahnf commented 4 years ago

Thanks for the feedback. :+1: My plan is to add hidraw support in the future (vibration and other device specific stuff), but it is not implement yet - so hidraw is ignored right now.

I am on the move right now and can look at your txt file tomorrow.

mayanksuman commented 4 years ago

I have started working on hidraw related changes. However, most of the issues are coming from the way the function ConnectDevices is defined. https://github.com/jahnf/Projecteur/blob/8cb1bd88c546016c650b97f2bf72b94588460517/src/spotlight.cc#L300

Do you want the Projecteur to connect to all the plug-ined devices?

jahnf commented 4 years ago

Do you want the Projecteur to connect to all the plug-ined devices?

Yes, and it will work in the current code base. E.g. you can plug in every device that is supported e.g. a Logitech Spotlight and an Avatto H100 at the same time. And even two devices of the same type (although that I havn't tested). This is not much different than the behavior in 0.7 where this was already possible. And I need to connect to all the event sub-devices for a device to make button mapping possible.

With hidraw (sub-devices) it's a little different. Connecting to a hidraw sub-devices (of a supported device) makes only sense if we know the protocoal (like the vibration on the Logitech device..)

So if you currently if I have an Avatto H100 and a Logitech Spotlight connected to your computer, the internal representation will look sth. like this: Usually each device will have a sub-device that is detected as a kind of mouse input device and one that is a keyboard device for the 'navigation' buttons.

Now if we have additional functionality for one of these devices that could only be achieved via hidraw, it would look like this.

All of these sub-devices can share a common button-mapper instance (at least that is my plan for now)

And I know the code is obscure in some places and (not yet) self-explaining - but it is a work in progress. My plan is to ignore hidraw sub-devices for the next release 0.8, this is planned for 0.9 - see also the milstone page: https://github.com/jahnf/Projecteur/milestones It's already a lot of changes for a release (maybe too many), with too many changes there is a much higher chance to introduce bugs.

In any case: I'm interested if you made progress with the hidraw communication. Maybe I can create a feature/hidraw branch where we work on hidraw changes towards 0.9? What do you think?

Also on another note and what is the actual topic of the issue :smile: : Does the fade in/ fade out work for you? (What Linux and Desktop are you using (e.g. OpenSuse/KDE) and are you using Wayland or X11?

mayanksuman commented 4 years ago

Yeah, I was thinking that in case of hidraw device support, it should be better to connect to only one device. hidraw device will also not need any button mapper. I guess you do not want all the connected device vibrating on timer. Additionally, Connecting to a single device is more logical given the device selection in Device tab of preferences of dialog box.

In any case: I'm interested if you made progress with the hidraw communication. Maybe I can create a feature/hidraw branch where we work on hidraw changes towards 0.9? What do you think?

Yes, please create the branch. The work is almost complete (with lots of refactoring of existing code due to above-stated reason). It is on branch feature/timer (on my fork). I guess I will be able to submit a pull request for the same in coming week.

Also on another note and what is the actual topic of the issue smile : Does the fade in/ fade out work for you? (What Linux and Desktop are you using (e.g. OpenSuse/KDE) and are you using Wayland or X11?

Yes, fade in/ fade out works for me. I am using Debian Testing/Gnome 3.36 with X11.

jahnf commented 4 years ago

Yeah, I was thinking that in case of hidraw device support, it should be better to connect to only one device.

I want to definitely keep the multiple connections. You can have multiple devices connected at the same time. The selection in device selection is for the purpose of showing connected devices - It will disappear when no device is connected. A vibration will only be set for the device selected for configuration anyway. You can also use this for testing quiet easily - just add -D Vendor:product to the command line and you normal usb mouse and you have your usb mouse as a spotlight device.

hidraw device will also not need any button mapper.

Why not? On the Logitech spotlight you you would still handle the mouse and keyboard via event devices - don't you? On my machines at least there the Logitech devices shows up as one mouse, one keyboard and one hidraw device - where the hidraw device handles stuff like vibrating and other special controls). A complete device connection (for the Logitech spotlight) consists of two event devices and one hidraw device I would think - and also for the hidraw connection there might be a button mapping useful - maybe the device indicates that the user long-pressed some button...

Yes, please create the branch. The work is almost complete (with lots of refactoring of existing code due to above-stated reason). It is on branch feature/timer (on my fork). I guess I will be able to submit a pull request for the same in coming week.

I'll create a branch soon. It will be quiet messy when you have refactored code base on code that is still work in progress is not finished yet and will be for v0.8 ... but until v0.9 it is still time :) And I will want to keep multiple device connection. But we will find a way.

Yes, fade in/ fade out works for me. I am using Debian Testing/Gnome 3.36 with X11.

Great to hear :)

mayanksuman commented 4 years ago

I want to definitely keep the multiple connections. You can have multiple devices connected at the same time. The selection in device selection is for the purpose of showing connected devices - It will disappear when no device is connected.

I think it might become a problem in real life situations. While presenting on a public PC with Projecteur, it may cause problem when multiple devices are connected (so someone other than presenter can interact with software/presentation). Instead many will prefer to have one device active at a time.

My changes are now complete and tested for the feature Vibration notification on timer. Please check out feature/timer branch on my fork.

jahnf commented 4 years ago

I will have a more detailed look at your changes later this weekend and comment there - we can keep the conversation going there or in the vibration related issue here.

Will close this issue for now since the fade-in/out seems to work. I will reopen it when when any issues with the overlay and the fade-in/fade-out arises.

maehne commented 4 years ago

@jahnf: I finally got around to test your develop branch (commit 5c2316fb) on my Progress Linux 5 (based Debian Buster) laptop with two attached screens and running the KDE Plasma desktop environment. Projecteur still works well as long as you stay with the spotlight on one screen. However, new bugs seem to have been introduced, which I did not observe in the past:

These bugs are not present in the projecteur 0.7 (installed via the DEB package from the releases tab) which I use currently in production.

jahnf commented 4 years ago

Thanks for testing and feedback. And darn it, but well kind of expected when tinkering with settings that work on a lot of environments by trial and error. But I if the problem is only while moving between screens I think I already know what to revert and still keep the fade in/out effect.

jahnf commented 4 years ago

@maehne If you have a chance, could you please give it another try with 23418af (which is 0.8-alpha.60)?

maehne commented 4 years ago

Wow, that was quick! I just checked with commit 23418afc and indeed the spotlight follows again smoothly the movements of the device. No jumping or getting stuck. :smiley:

I got two ideas while testing:

jahnf commented 4 years ago

Wow, that was quick! .... No jumping or getting stuck. smiley

Well I was working on the project right now :) - great that it works again.

How about having an option that all screens get dimmed when the spotlight is active so that spotlight movements across multiple screens look more natural?

Good idea :+1: , might be possible - it would involve multiple overlay windows though (one per screen). I'll remember to try that at some point.

If you want to use the spotlight for explanations over a longer time, it can be tiresome to have to leave the thumb on the button. How about an option where with one click on the device button the spotlight is turned on and with another click the spotlight is turned off? A kind of spotlight locking function might be even more intuitive: I the spotlight button got pressed for a configurable amount of time (e.g. 3 or 5 sec), it remains on -- even if the button is released. Only a second press on the button will turn it off again.

Things like that will be possible with the button mapping functionality I am working on for the next release - maybe not all kind of combinations right from the start but Projecteur will get there - at least that is my plan. So if the user wants to, all buttons (or button sequences) they can be mapped to either a defined key-press or some action (e.g. toggle the spot??) Can't promise a date on this yet though.

maehne commented 4 years ago

Thanks for the quick feedback on my ideas. Should they get their own issues? I don't need urgently that functionality. I am already quite happy with the current state of Projecteur and how it has evolved over time.

jahnf commented 4 years ago

Button mapping has already an issue (#69) - But for the multi-screen overlay, yes. Please create an issue, it is much easier tracked that way and not forgotten inside some long closed issue.