To be fair, it actually does work out of the box, but shortcut mapping doesn’t really work well outside of the buttons on the pen itself and pressure curves isn’t customizable yet, at least on KDE.
You don’t execute C source files. They have to be compiled.
First point as someone else commented, that driver is already present in any mainstream kernel. It’s very unlikely you have any need to build it.
But if you really want to build it the command will be make that will get instructions from Makefile on how to build the driver. But there will be other tools and libraries needed.
I did what abominable_panda suggested and it returned a “wait_queue_t” and a couple of pointer type errors. I’m not sure if that’s something that could be fixed with installing something else, but I’m not at all familiar with troubleshooting on this OS yet. The troubleshooting part you mentioned is if it successfully installed but there are issues. It doesn’t quite explain the initial installation part.
As for cmnybo’s question, I’m trying to program a ESP32 module with the Arduino IDE. I’ve tried just plugging it in and hoping the driver would already be installed but lsusb doesn’t show it on the results.
If it’s not showing up in lsusb and there is no activity in syslog when connecting or disconnecting it, then the problem is not a driver. It’s likely a bad cable or you got a dead module.
You’re right about the bad cable. I have a collection of about 10 USB A to USB micro cables and only one of them showed up on lsusb! Thanks for the advice!
*.c files are C source files, you can’t run these directly. Run the makefile with sudo make or sudo make install (assuming you have make installed) to build (or build and install) the driver.
edit: Oops didn’t read far enough into your post, you’ve already tried make. What error does it give you?
You don’t pass in Makefile to make as it will read that file automatically. Nor you need sudo with make as compiling doesn’t need any special privileges.
Step:
make: compile the code to binary
sudo make install: install the binary to your system
can’t really tell much without knowing this package, but ./ is not what you’re looking for. try just “make” or “make clean”, as this is standard syntax for Makefiles. if you are wondering what happens, make looks for a file called “Makefile” in the current directory and executes whatever is inside. in your case it will most likely compile the .c file into an executable
Some time ago I wasted about 2 hours of time because of that damn brltty, wondering why the tf the arduino was not being detected until I followed dmesg. I was very upset at the time when I found out what brltty was. Like I get some people need that but if the user did not connect a braille display during install then the daemon should never be enabled or just uninstalls during os installation.
Your description is a bit misleading. Distrobox allows you to run a container that is integrated with the system. This means you can have a command line that is basically the other distro but you can still access files and run GUI apps.
In September the NixOS constitutional assembly should finish their work, and the community will be able to elect governance. I’m guessing that’s when the drama will start getting resolved.
In the meantime, there are multiple maintainers that have left because of the drama - which is more troublesome than the board members leaving - but nixpkgs has a LOT of maintainers, and there are new ones joining all the time. It’s still healthy and won’t implode so quickly.
I heard developers find it rather easy to do reproducible build in Nix, so it is more utilized over dev landscape. Basically a competitor of docker, and quite significant one at that. That’s why it is considered big, despite that it is niche from desktop linux pov.
It’s probably wise to simply ignore the drama. Open source seems to invite this at the “top” for whatever reason, but for the casual user there is usually little to no impact.
Unless you’re trying to be a top contributor to nix, I would just carry on with normal usage and all the current drama will blow over.
Idk imo knowing about the drama makes me hesitant to go back, especially since I switched all my development environments from Nix to Guix and I dont want to have three package managers lol Plus the Guix community seems really close knit
Conway’s Law applies in this respect; the mess in governance of Nix has produced a product that reflects that mess. Nix started a beautiful movement but like many first movers, they rarely reap long-term rewards.
All good reasons to make a decision, I’m not trying to sway anyone in a direction.
I just feel bad when people see drama in a community and wonder if that thing is “safe”. I’ve seen this kind of thing many times before in other communities—PERL, Python, Ruby, Rust, etc—and it never seems to lead to sweeping changes the normal user would notice. It’s pretty safe to assume that day-to-day users of thing can just carry on if they don’t care about the community upset.
That’s true. That’s what I’ve been seeing in places, people just saying to continue on and ignore the drama. And I know I shouldn’t let a group idea/thing dictate whether I use nix but like I was already starting to not like how it seemed like a lot of people were like “write all your stuff in nix (configs, etc)” and I didn’t want to get locked in. Plus I got busy and didn’t feel like tinkering with it. Idk. I was already losing interest in a weird way. I still think immutable/reproducible distros are cool though. I’m now just currently running Guix on top of arch and using aconfmgr to emulate some reproducibility.
NixOS is never going mainstream. When the answer to everything is oh just write a package for it. Unless their is a nice gui to edit your configuration file also it well always be niche.
Not to add fuel to the flame by asking, but how’s it been on Guix? I’ve heard Guix does a lot of things better, but also that there’s far less packages and it’s harder on modern hardware.
I’m not the op, but I’ve been using guix for several months on a new fairly top of the line desktop PC and it’s going great. I’ve been able to play steam games and set up my dev environment with basically no issues.
The catch is you need to use non-official repositories (i.e. github.com/nonguix/nonguix) to use the non-libre kernel and other software not on the official channel.
There’s also this nice little search engine - https://toys.whereis.みんな/ - where you can look for packages from other repos (or channels as they are called in guix).
I use Nix on my macos work laptop to set up my dev environment, but I definitely prefer guix so far, mostly due to the it being configured in guile over the weird nix language. The biggest advantage I see of Nix is that it has a bit more features and lots more packages.
I am a pretty hardcore emacs user and lisp lover though, so ymmv.
They literally have this as the link in all their docs so I am not sure why you would choose the mirror on the fully-proprietary, Microsoft-owned code forge.
I haven’t tried running a full Guix system yet but im really liking it as a package manager on top of arch. Yes, hardware support can be iffy, but there is an unofficial channel called nonguix that packages the standard Linux kernel instead of linux-libre, and yes there are less packages but honestly packages are so much more fun to write? I’ve written a few package definitions for both my own use and ive made a request to add one to the official channel. And I feel like, if I really needed something that would not be packaged due to complexity or something, I could try and use flatpak or an appimage or something. I think its definitely worth checking out.
uh, the drama being what it is about people in positions of power blocking efforts to make a welcoming and diverse nixos community, persisting right wing concern trolling, and especially what appears to be maybe a military tech company takeover of nixos, it’s hella understandable people would want to reconsider using this tech on their own hardware and it’s pretty sus to respond to this with ‘ah just drama it’ll blow over’…
Of how much “militsry” contributed to FOSS. Or how Linux is no longer the lone programmer hacking on code in there spare time. But the vast majority of FOSS is done by companies.
You don’t have to read the source code. You just clone the repo and run make to install it. Then just run the lswt command which will show you app-ids of any running apps.
Have you setup a rules file for USB? You must have a udev rule setup that gives your user access to the hardware. It is trivial to create, but is one of those little headaches you learn as you go. Sparkfun and Adafruit should both have good tutorials if you search either of them for udev rules.
I just told you to enter the terminal editor nano and enter a note that will help you remember that this is for the ch340 # ch340 followed by a line that sets the permissions for the device using a rule for which users have access to the device. I’m assigning the rule based on the vendor and product ID numbers. You can find these numbers by using the $ lsusb command. FYI, the $ is standard shorthand for command line as your standard user. This is opposed to # which is short for the root user at the command line.
Once you enter this line in nano, follow the instructions to save the file in nano :qw IIRC. The next time you plug in the device, the kernel should use this rule to set the permissions for the device to 0666 which means everyone can read write, but not execute stuff from the port; with execute would be 0777.
When you are trying to find info about a USB device the following may be helpful:
Note that the last line should be the most recently connected device. $ dmesg is the system-d boot log. Depending on how system-d is configured, you’ll probably see timestamps on the left. The initial bootup devices will show up with a tightly grouped time stamp, while later connections will show a much larger number.
There have been some recent changes in Fedora that have broken a script I wrote to help me with all the various places where USB hardware is located and finding the right info. I’m trying to parse that script for the key elements. The first step is to find the location of the hardware. You are looking for something like /dev/bus/usb/003/003 or wherever the new device got mounted. This is only the start, because different parts of the device may be mounted in different locations. I’m not just talking about the CH340, but like, if you are doing microcontrollers stuff that gets more complicated like forth, micropython and circuit python where there will be more going on than just the serial port, or you need to know low level stuff. Once you know the specific port, you can use $ udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/bus/usb/003/003) # enter the port for the device in question.
In the past, my script used $ dmesg to retrieve the device location, then used $ lsusb -D *device location* to get the basic info. Then I went a layer deeper with the udevadm command to see everything related to the device. The command $ fdisk -l might also help with some STM32 type stuff that has a dfu bootloader and identifies as a USB drive when plugged in… At least, I think that was the reason I kept that option in my script, it has been awhile since I used one of those.
Edit: I can get the actual port location of a device now using $ lsusb -t -vv.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.