support for extended adjustable dpi

[pfps]

Fixes #2207

[pfps]

Yes indeed.

[pfps]

Yes indeed. Should be fixed now

[CuteSC2]

The mouse is not shown at all, something broke :(

solar4.log

[CuteSC2]

It lives!!

[CuteSC2]

solar dpi change.log
welp, but changing the dpi results in an exception

[pfps]

Does your mouse have both X and Y dpi? Solaar only gets and sets the X dpi and I'm not sure what this does for a mouse with both.

The Pro X 2 appears to have lots of possible dpi values. Does this slow Solaar down appreciably?

What happens if you try to change the DPI with an active profile?

[pfps]

What happens with the exception? Solaar should just mark the setting as in an error state and proceed.

What is happening is that for some devices an active onboard profile prevents changes to the DPI. Try turning off onboard profiles and see what happens.

[CuteSC2]

now a different error with onboard profiles disabled
solar dpi error.log

[pfps]

My guess is that your mouse supports different resolutions for X and Y directions and that 0 is not allowable for the Y direction.

There are several ways to support this. I'll try the simplest - one that assumes that all valid X resolutions are also valid Y resolutions.

[pfps]

The current version of the PR makes some allowances for y direction DPI but assumes that it can be set the same as the x direction DPI. I had thought that it would be a lot of work to separate them, but it may not be too difficult in the end.

But please try out this version and post the result of solaar -ddd from startup to an attempt to change DPI.

[pfps]

@MattHag I removed the pip-installed Solaar on my machine and now I'm experiencing strange effects with pytest.

pytest --cov-report term-missing --cov=lib/logitech_receiver tests/logitech_receiver/test_hidpp20_simple.py 

generates a reasonable coverage report, but

pytest --cov-report term-missing --cov=lib/logitech_receiver tests/logitech_receiver/test_setting_templates.py 

produces the warning /home/pfps/.local/lib/python3.12/site-packages/coverage/control.py:887: CoverageWarning: No data was collected. (no-data-collected) self._warn("No data was collected.", slug="no-data-collected") and the coverage report shows no coverage at all even though a lot of tests were run.

Any ideas on what is going on?

[MattHag]

No, I don't know. But the coverage on GitHub is mostly lower than local.

[DexterHaxxor]

Getting the same error as described by CuteSC2 even after these commits

[pfps]

See the bug issue for this change.

[MattHag]

Regarding the coverage, that could be caused by a seg fault, which I get at least locally from one test.