per-device config

[BKSalman]

is there a way to have a per-device config? I have a trackball which I want to use acceleration with, and a regular mouse which I don't want to use any acceleration with, so I want to limit yeetmouse to only accelerate the trackball, or maybe have different configs for different mice so I can set the acceleration to 0 on the regular mouse

[AndyFilter]

Hey, unfortunately, I believe that there is no way to do this as of now. YeetMouse attaches to the HID driver, and only filters devices based on capabilities. Though I think someone has at least made an attempt to do separate configs for different devices on NixOS, so if that's any helpful, here's the link: #23 (comment).
One thing you could do is filter out the devices straight in the source code (in the function I referenced earlier) based on the vendorId perhaps, but yea... that's not a nice way to do it.

[AndyFilter]

It actually does look quite good when combined with the style of the mode buttons. I also added a green highlight to show the devices that have an override.

YeetMouseDeviceSelection-2026-05-02_10.35.56.webm

But I still don't know how the default config should be treated. I tried adding checkboxes to enable/disable acceleration for a given device, but it doesn't look as good:

But it's good enough tbh.

Here's the prototype code for it, in case you want to go with this:

        // Device selection
        ImGui::SeparatorText("Device");
        static int selected_dev = 0;
        constexpr char* Devices[] = {"Keychron M6", "Logitech G502", "Generic Mouse", "Global"};
        static bool enabled_devices[] = {true, true, false, true};
        ImGui::SetNextItemWidth(-1);
        if (ImGui::BeginCombo("##Select device", Devices[selected_dev])) {
            for (int i = 0; i < std::size(Devices); i++) {
                bool is_selected = (i == selected_dev);
                bool is_overwritten = Devices[i][0] == 'L'; // Just the logitech to show how it looks
                ImGui::PushID(i);

                ImGui::PopStyleVar(); // Pop the style to avoid huge checkboxes
                ImGui::Checkbox("##Device_Checkbox", &enabled_devices[i]);
                ImGui::SameLine();
                ImGui::PushStyleVar(ImGuiStyleVar_FramePadding, {12, 12});

                ImGui::BeginDisabled(!enabled_devices[i]);

                if (is_overwritten) // Mark the overwritten device
                    ImGui::PushStyleColor(ImGuiCol_Text, ImVec4(ImColor::HSV(0.35, 0.35, 0.9)));
                if (ImGui::Selectable(Devices[i], is_selected)) {
                    selected_dev = i;
                }
                if (is_selected)
                    ImGui::SetItemDefaultFocus();

                if (is_overwritten)
                    ImGui::PopStyleColor();

                ImGui::EndDisabled();
                ImGui::PopID();
            }
            ImGui::EndCombo();
        }

it should be inside the if (ImGui::BeginChild("Modes", ImVec2(220, 0), ImGuiChildFlags_FrameStyle)) {.

[BKSalman]

It actually does look quite good when combined with the style of the mode buttons. I also added a green highlight to show the devices that have an override.
YeetMouseDeviceSelection-2026-05-02_10.35.56.webm

Yep! looking good

But I still don't know how the default config should be treated. I tried adding checkboxes to enable/disable acceleration for a given device, but it doesn't look as good

maybe a None acceleration mode could be added, and would be listed on the side with the other acceleration modes

Here's the prototype code for it, in case you want to go with this

🫡 thanks, hopefully I have time today to work on it

btw, do you think I should open a PR? maybe with the same branch? (it will be a draft for now tho)

[AndyFilter]

maybe a None acceleration mode could be added, and would be listed on the side with the other acceleration modes

Currently you can just set the Linear mode with acceleration set to 0.
As you can see from that error message, it's natively supported...😁:

YeetMouse/driver/accel_modes.c

Lines 45 to 50 in 63f1334

	if (g_AccelerationMode == AccelMode_Linear) {
	if (g_Acceleration == 0) {
	printk("YeetMouse: Error: Acceleration mode 'Linear' is not supported for acceleration 0.\n");
	g_Acceleration = 0;
	g_AccelerationMode = AccelMode_Current;
	}

(It'll just skip the acceleration part all together with the AccelMode_Current mode)

That's why I think it'd be better to add the checkboxes. It's a mouse acceleration software after all, disabling the acceleration is not a standard procedure. But I guess adding a None, or Off acceleration mode would not be a bad idea.

btw, do you think I should open a PR? maybe with the same branch? (it will be a draft for now tho)

Yea, you can. But no pressure, open the PR once you feel ready for it.

[AndyFilter]

Hey, just an idea that popped into my head recently. Perhaps it'd be best to leave the current config handling as is (in /sys/module/yeetmouse/parameters), and just add a new layer on top. So that the driver always loads the global config, and then if it finds a local config for a given device it uses that instead.
This, I think would be beneficial mostly for compatibility reasons - as it wouldn't change anything (hopefully) for most of the users who don't use per-device configs. And less changes means less ways it can break. And knowing things like this - it will break, haha.
Now, when it comes to the implementation, I think the best way is to pass the accel_params* to the accelerate function (like it's done on your branch) and just use a nullptr if the driver doesn't detect - a valid - config for it. Then inside the accelerate function you'd have an if to check whether the parameters value is nullptr and if so, replace it with a global config; rest stays the same.

What do you think about this?

[BKSalman]

Yeah, that makes sense, I will keep that in mind!

Yesterday I worked on moving some static variables from inside functions to the mouse_state so every mouse would have its own, my code currently doesn't work if the user tries to use the old configuration method, but I will make sure to add that back, I kinda made some big changes tbh, one of them is removing the need for the user to provide lut_size, and it being derived when the user writes lut_data, and generally moving validation to the store callback, instead of having it in the mouse_events callback, and removing the need to call update to update the params (this is not a technical limitation, just a decision I took to make it easier to implement, and I can add it back), I'm generally trying to separate the parts of the code that modify the params and validate it, from the parts that read the params

These changes might look like I'm ignoring your suggestions from before, but I'm just trying to separate things a little, and hopefully make the code cleaner and easier to reason about where it modifies stuff and where it doesn't, but your review on the changes would be helpful as usual 🫡