Re: [systemd-devel] Scan all USB devices from Linux service
This is what ChatGPT proposes:
#include
#include
void scan_devices(const char* target_string) {
libusb_device **devs;
libusb_context *ctx = NULL;
int r;
ssize_t cnt;
r = libusb_init();
if (r < 0) return;
cnt = libusb_get_device_list(ctx, );
if (cnt < 0) return;
for (ssize_t i = 0; i < cnt; i++) {
libusb_device *dev = devs[i];
libusb_device_handle *handle = NULL;
if (libusb_open(dev, ) == 0) {
// Iterate through all configurations and interfaces
struct libusb_config_descriptor *config;
libusb_get_config_descriptor(dev, 0, );
for (int j = 0; j < config->bNumInterfaces; j++) {
const struct libusb_interface *inter =
>interface[j];
const struct libusb_interface_descriptor *interdesc =
>altsetting[0];
if (interdesc->iInterface) {
unsigned char buffer[256];
int len = libusb_get_string_descriptor_ascii(handle,
interdesc->iInterface, buffer, sizeof(buffer));
if (len > 0) {
printf("Interface %d: %s\n", j, buffer);
if (strcmp((char*)buffer, target_string) == 0) {
// Match found
printf("Match found for interface %d\n", j);
}
}
}
}
libusb_free_config_descriptor(config);
libusb_close(handle);
}
}
libusb_free_device_list(devs, 1);
libusb_exit(ctx);
}
int main() {
scan_devices("Particular String");
return 0;
}
On Wed, Feb 14, 2024 at 3:54 PM Muni Sekhar wrote:
> HI all,
>
> USB devices can have multiple interfaces (functional units) that serve
> different purposes (e.g., data transfer, control, audio, etc.).
>
> Each interface can have an associated string descriptor (referred to
> as iInterface). The string descriptor provides a human-readable name
> or description for the interface.
>
> From user space service utility, How to scan all the USB devices
> connected to the system and read each interface string
> descriptor(iInterface) and check whether it matches "Particular
> String" or not.
>
> The service program should trigger scanning all the USB devices on any
> USB device detection or removal. Can libusb be used for it?
>
> Any input would be appreciated.
>
> --
> Thanks,
> Sekhar
>
Re: [systemd-devel] Scan all USB devices from Linux service
On Mi, 14.02.24 20:24, Muni Sekhar (munisekhar...@gmail.com) wrote: > HI all, > > USB devices can have multiple interfaces (functional units) that serve > different purposes (e.g., data transfer, control, audio, etc.). > > Each interface can have an associated string descriptor (referred to > as iInterface). The string descriptor provides a human-readable name > or description for the interface. > > >From user space service utility, How to scan all the USB devices > connected to the system and read each interface string > descriptor(iInterface) and check whether it matches "Particular > String" or not. You can use sd-device.h, allocate an sd_device_enumerator_new(), then apply some filter via sd_device_enumerator_add_match_sysattr() and then enumerate through it via sd_device_enumerator_get_device_first()/sd_device_enumerator_get_device_next(). Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Scan all USB devices from Linux service
On Wed, Feb 14, 2024 at 08:24:25PM +0530, Muni Sekhar wrote: > HI all, > > USB devices can have multiple interfaces (functional units) that serve > different purposes (e.g., data transfer, control, audio, etc.). > > Each interface can have an associated string descriptor (referred to > as iInterface). The string descriptor provides a human-readable name > or description for the interface. > > >From user space service utility, How to scan all the USB devices > connected to the system and read each interface string > descriptor(iInterface) and check whether it matches "Particular > String" or not. Just write some code to do so using either libusb, or your own sysfs scanning logic or talk directly to all of the usb devices using usbfs. > The service program should trigger scanning all the USB devices on any > USB device detection or removal. Can libusb be used for it? For detection/removal, no, libusb isn't for that. udev can provide you the needed callbacks to your code for that situation. But what problem are you trying to solve that isn't already handled by the kernel and userspace usb handling logic already? good luck! greg k-h
[systemd-devel] Scan all USB devices from Linux service
HI all, USB devices can have multiple interfaces (functional units) that serve different purposes (e.g., data transfer, control, audio, etc.). Each interface can have an associated string descriptor (referred to as iInterface). The string descriptor provides a human-readable name or description for the interface. >From user space service utility, How to scan all the USB devices connected to the system and read each interface string descriptor(iInterface) and check whether it matches "Particular String" or not. The service program should trigger scanning all the USB devices on any USB device detection or removal. Can libusb be used for it? Any input would be appreciated. -- Thanks, Sekhar
Re: [systemd-devel] Issue with systemd-logind
On Mi, 14.02.24 15:03, Akshaya Maran (akshayamara...@gmail.com) wrote: > Hi, > > I am trying to run weston11.0.1 using systemd logind launcher but got this > error > " logind: failed to get session seat > logind: cannot setup systemd-logind helper error:" This looks like an error message from some weston thing. Please ask that community for help. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Issue with systemd-logind
Hi, I am trying to run weston11.0.1 using systemd logind launcher but got this error " logind: failed to get session seat logind: cannot setup systemd-logind helper error:" I referred to yocto build . I added weston.service,weston.socket,weston-autologin,weston-start and other files attached and exported a few variables . And also created weston user . Should I run in root/ weston user ? When I tried to boot , I could see a log for loginctl seat0 but not attached to the loginctl session. Am I missing any additional packages or services or any files that need to be added ?? I am attaching my log and files I used . Can you please help me to understand and solve this issue? Thanks, Akshaya weston_log_14_2_24 Description: Binary data profile Description: Binary data # This is a system unit for launching Weston with auto-login as the # user configured here. # # Weston must be built with systemd support, and your weston.ini must load # the plugin systemd-notify.so. [Unit] Description=Weston, a Wayland compositor, as a system service Documentation=man:weston(1) man:weston.ini(5) Documentation=http://wayland.freedesktop.org/ # Make sure we are started after logins are permitted. Requires=systemd-user-sessions.service After=systemd-user-sessions.service # If Plymouth is used, we want to start when it is on its way out. After=plymouth-quit-wait.service # D-Bus is necessary for contacting logind. Logind is required. Wants=dbus.socket After=dbus.socket # Ensure the socket is present Requires=weston.socket # Since we are part of the graphical session, make sure we are started before # it is complete. Before=graphical.target # Prevent starting on systems without virtual consoles, Weston requires one # for now. ConditionPathExists=/dev/tty0 [Service] # Requires systemd-notify.so Weston plugin. Type=notify EnvironmentFile=/etc/default/weston ExecStart=/usr/bin/weston --modules=systemd-notify.so # Optional watchdog setup #TimeoutStartSec=60 #WatchdogSec=20 # The user to run Weston as. User=weston Group=weston # Make sure the working directory is the users home directory WorkingDirectory=/home/weston # Set up a full user session for the user, required by Weston. PAMName=weston-autologin # A virtual terminal is needed. TTYPath=/dev/tty7 TTYReset=yes TTYVHangup=yes TTYVTDisallocate=yes # Fail to start if not controlling the tty. StandardInput=tty-fail StandardOutput=journal StandardError=journal # Log this user with utmp, letting it show up with commands 'w' and 'who'. UtmpIdentifier=tty7 UtmpMode=user [Install] # Note: If you only want weston to start on-demand, remove this line with a # service drop file WantedBy=graphical.target [Unit] Description=Weston socket RequiresMountsFor=/run [Socket] ListenStream=/run/wayland-0 SocketMode=0775 SocketUser=weston SocketGroup=wayland RemoveOnStop=yes [Install] WantedBy=sockets.target weston-start Description: Binary data weston-autologin Description: Binary data init Description: Binary data weston.ini Description: Binary data
Re: [systemd-devel] ConditionNeedsUpdate, read-only /usr, and sysext
On Mi, 07.02.24 20:42, Valentin David (m...@valentindavid.com) wrote: > Hello everybody, > > The behavior of ConditionNeedsUpdate is that if /etc/.updated is > older than /usr/, then it is true. > > I have some issues with this. But maybe I do not use it the right > way. > > First, when using a read-only /usr partition (updated through > sysupdate), the time of /usr is of the build of that filesystem. In > the case of GNOME OS, to ensure reproducibility bit by bit, we set > all times to some time in 2011. So that does not work for us. Hmm, I wonder if the os-release file in /usr/ should optionally have a timestamp field which could be used. That could be directly initialized from $SOURCE_DATE_EPOCH at build time (maybe the field should even be named like that). I think that would make sense, no? > But now let's say we work-around that, and we make our system take a > date that is reproducible, let's say the git commit of our > metadata. Then we have a second issue. > > Because of systemd-sysext, it might be that /usr is not anymore the > time of the /usr filesystem, but the time of a directory created on > the fly by systemd-sysext (or maybe it keeps the time from the / > fileystem, I do not know, but for sure the time stamp is from when > systemd-sysext was started). If systemd-update-done happens after > systemd-sysext (and it effectively does on 254), then the date of > /etc/.updated will become the time when systemd-sysext started. Uh. That'd be a bug. Can you file an issue about this? > Let's imagine that I do not boot that machine often. My system is > booting a new version. And there is already another new version > available on the sysupdate server. My system will download a build > of /usr that is likely to be older than the boot time. So next > reboot, the condition will be false, even though I did have an > update. And it will be false until I download a version that was > built after the boot time of my last successful update. > > So my question is, is there plan to replace time stamp comparison > for ConditionNeedsUpdate with something that works better with > sysupdate and sysext? Maybe copying IMAGE_VERSION from > /usr/lib/os-release into /etc/.updated for example? Yeah, we should fix this. I have so far never though about the mixture of sysext and ConditionNeedsUpdate=. This is unchartered territory. But I think we can fix this. But please open issues about this. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Wireguard routes only after connect
Hi, is there a possibility to only add the routes from allowed-ips to the kernel routing table after the peer has connected? Because since the tunnel itself is stateless, there is no way for me to make use of OSPF to route packets to a selective server running a tunnel to the same endpoint (for loadbalancing and multi-wan reasons).
