sorted by: new top controversial old
BMW is putting Spider-Man ads on your dashboard, after promising it never would in c/technology@lemmy.world
BMW is putting Spider-Man ads on your dashboard, after promising it never would in c/technology@lemmy.world
[–] 19 points 3 months ago (4 children)

When my wife bought a new Mazda, the dealer made her sign a form that said the remote start app would only be free for one year. He told her it was just boiler plate; the remote start app would be free forever. I knew when she bought the vehicle the remote start app would be a monthly charge starting in precisely one year. lol!

  • permalink
  • fedilink
  • source
    •
    Okay why is your distro the best? in c/linux@programming.dev
    [–] 1 point 5 months ago*

    I slightly regret switching one of my development machines from Manjaro to EndeavourOS. At the time, I needed to test an app I was writing with ffmpeg v8.0 and Manjaro was not going to have that for quite some time. I tried the AUR package but it didn't work and I had to back it out.

    EndeavourOS is absolutely great. I literally am not aware of a single flaw in it. My regret, infinitesimal as it is, is based on being so close to upstream projects. I would far, far rather have a stabilized distro.

    My Manjaro machine, for example, has a perfect KDE right now. My EndeavourOS requires directory renaming 2 to 4 times to get it to stick. I know that's not EndeavourOS. It's KDE but I vastly prefer a distro with some quality control.

    Meanwhile, Manjaro turned into a dumpster fire so there's no point going back. I do have one machine on Manjaro and it's running fine, taking the extremely occasional update. I may go to Fedora LXQt spin but EndeavourOS is great, except for the Dolphin issue. They may have fixed it by now but I'm too scared to take any updates in case it gets worse.

  • permalink
  • fedilink
  • source
    •
    Flatpak’s Future May Leave Non-systemd Distros Behind in c/linux@programming.dev
    [–] 9 points 5 months ago (1 child)

    No problem. I'm drifting away from flatpak, anyway. Anything that's married to systemd is going to be a problem for an increasing number of people, over time.

  • permalink
  • fedilink
  • source
    •
    Anyone get a Royal Kludge R75 working under linux and Vial? in c/linux@lemmy.ml
    [–] [S] 1 point 1 year ago

    The problem seems to be lack of ability to give the board a magic serial number. The vial app looks for a specific string in the serial number ("vial:") to identify a vial capable keyboard. My R75 won't accept a serial number, no matter what I do.

    Apparently, this is a limitation of some cheap USB controllers (always answer 0 to all serial requests). I don't know if that's true but ChatGPT tells me it's so.

    udevadm info -a -n /dev/hidraw$(ls /dev/hidraw* | tail -1 | tr -dc '0-9') | grep -i serial  2 ✘ ATTRS{serial}=="00000000000000000000000000000000" ATTRS{serial}=="0000:09:00.0"

    Apparently, the magic number can be coded into the UID, also. I'm working on that, too, with no success so far. Apparently, USB controllers don't stand in for UID in any case.

    I'm struggling with this. If anyone has some ideas or clear direction, I would consider it a favor. If I can manage to make it work, I'll publish the firmware for everyone.

    Even if someone got the mossbed firmware to work, that would be helpful to know. I have been banging on it for three days with no luck. This is the most expensive, cheap keyboard I've ever purchased. lol!

  • permalink
  • fedilink
  • source
    •
    12
    Anyone get a Royal Kludge R75 working under linux and Vial? (lemmy.world)
     

    My R75 works fine under via.

    I'm using the R75 vial firmware located here.

    https://github.com/mossbed/r75

    It won't compile, as cloned. It's more than just the directory structure which is completely silly. It's not surprising it didn't work, given it's messy state. I had to modify it a bit, so it could easily be something I did.

    I had to add a UID:

    config.h -> #define VIAL_KEYBOARD_UID { }

    and uncomment tap_dance_action in keymap.c.

    tap_dance_action_t tap_dance_actions[] = { [TD_RESET] = ACTION_TAP_DANCE_FN(safe_reset), [TD_CLEAR] = ACTION_TAP_DANCE_FN(safe_clear), [TD_CTL_TG] = ACTION_TAP_DANCE_LAYER_TOGGLE(KC_RCTL, _CTL_LYR) };

    That's about it.

    It compiles and downloads cleanly. Via continues to work but Vial does not discover it.

    This mosbed firmware extension claims to be a derivative of this work but it doesn't seem to be.

    https://github.com/irfanjmdn/r65/tree/vialrgb?tab=readme-ov-file#guide

    Anyone have Vial working? It's a popular keyboard so I expect someone has solved this problem. If no one responds, I'll take it on in a week or so so we can all enjoy ou R75 on linux with Vial.

    I need some high level guidance on UDEV rule for an HIDAPI driver in c/linux@programming.dev
    [–] [S] 1 point 1 year ago

    Thanks. He has the core done. It could have saved me some time. I'm quite a bit further along with auto discovery and a couple of minor conveniences.

    If I can get it to install with a UDEV rule so it runs at user privilege level, it'll be all set and I'll push it into the AUR.

  • permalink
  • fedilink
  • source
  • parent
  • context
    • I need some high level guidance on UDEV rule for an HIDAPI driver in c/linux@programming.dev
    6
    I need some high level guidance on UDEV rule for an HIDAPI driver (lemmy.world)
     

    Like a lot of Chinese devices, my TEMPer clone creates two HID interfaces. This isn't how TEMPer is supposed to work but this unit is a knock-off. It was purchsed from Amazon and I tried to get an authentic part (Got from Amazon. The brand looked right and it wasn't the cheapest TEMPer, by far, but turned out to be a junky knock-off).

    Right now, the app only works with root permission. I need to get it completely into the user space

    Anyway, it creates two HIDRAW dev interfaces. The first one does not work. It responds on the second one. It always seems to show up on /dev/hidraw3 but I understand this cannot be counted on after re-plug, reboot, or other installs.

    How can I create a udev rule that will allow my app to find the device (either scan with HIDAPI or libusb) and create symlink under /dev with user space access that my app can interface with?

    Or, perhaps there is a better way?

    I'm trying to write a driver that anyone can use with a knock-off TEMPer.