libusb_open - LIBUSB_ERROR_ACCESS

[Garfield]

http://www.linux-usb.org/usb-ids.html

Die Liste wollte ich nicht einbinden.

[theo]

http://www.linux-usb.org/usb-ids.html

Die Liste wollte ich nicht einbinden.

Tja, ist wohl nichts für Warmduscher!
Wenn du lsusb nachbauen willst, würde ich dort nachschauen:
https://fossies.org/linux/usbutils/lsusb.c
https://fossies.org/linux/usbutils/names.c
etc.

Mir wäre das aber etwas zu heftig.

[Garfield]

Danke. Ich will das nicht komplett nachbauen. Nur das, was da angezeigt wird.

In der listcevs.c steht:

Code: Alles auswählen

if (verbose) {
			r = libusb_get_device_string(dev, LIBUSB_DEVICE_STRING_MANUFACTURER,
				string_buffer, sizeof(string_buffer));
			if (r >= 0) {
				printf("\n    manufacturer = %s", string_buffer);
			}

			r = libusb_get_device_string(dev, LIBUSB_DEVICE_STRING_PRODUCT,
				string_buffer, sizeof(string_buffer));
			if (r >= 0) {
				printf("\n    product = %s", string_buffer);
			}

			r = libusb_get_device_string(dev, LIBUSB_DEVICE_STRING_SERIAL_NUMBER,
				string_buffer, sizeof(string_buffer));
			if (r >= 0) {
				printf("\n    serial_number = %s", string_buffer);
			}
		}

Der Function libusb_get_device_string wird das Gerät übergeben und man bekommt die gewünschten Strings. In der https://libusb.sourceforge.io/api-1.0/l ... ource.html (2421 Zeilen) gibt es die Funktion nicht. Aber in der https://github.com/libusb/libusb/blob/m ... b/libusb.h (2453 Zeilen zwei Monate alt).

[Mathias]

Die kann ich nachvollziehen. Auf github gibt es diese Funktion, aber in meinen header von Mint gibt es sie nicht.
Ich denke am nächsten Sommer wen die das neue Mint und das Ubuntu stable kommt, wird die Funktion standardmässig dabei sein.

[Garfield]

Heißt also auf die 1.0.30 warten.

umain.pas(85,1) Error: (.text.n_umain$_$tfrmusb_$__$$_btndeviceclick$tobject+0x27c): undefined reference to `libusb_get_device_string'

[Garfield]

Da gibt es Anhaltspunkte.

https://fossies.org/linux/usbutils/lsusb.c

Code: Alles auswählen

267     get_vendor_product_with_fallback(vendor, sizeof(vendor),
268             product, sizeof(product), dev);

https://fossies.org/linux/usbutils/names.c

Code: Alles auswählen

   95 const char *names_vendor(uint16_t vendorid)
   96 {
   97     char modalias[64];
   98 
   99     sprintf(modalias, "usb:v%04X*", vendorid);
  100     return hwdb_get(modalias, "ID_VENDOR_FROM_DATABASE");
  101 }
  102 
  103 const char *names_product(uint16_t vendorid, uint16_t productid)
  104 {
  105     char modalias[64];
  106 
  107     sprintf(modalias, "usb:v%04Xp%04X*", vendorid, productid);
  108     return hwdb_get(modalias, "ID_MODEL_FROM_DATABASE");
  109 }

Die hwdb.bin ist die Datenbank mit den VID und PID. Habe ich in /etc/udev und /lib/udev. Wird anscheinend mit den USBUtils installiert.

[theo]

@Garfield: Das meine ich ja. Wenn du die gleichen Angaben sehen willst wie lsusb ausgibt, dann musst du auch diese Methoden verwenden. Aus der libusb allein kommt das nicht.

Allgemein ist mir nicht klar, was genau dein Ziel bzw. deine Bedingungen ist/sind.
Wenn es nur für Linux ist, würde ich persönlich einfach die Ausgabe von lsusb einlesen und gut.
https://wiki.lazarus.freepascal.org/Exe ... l_Programs

Die neue libusb Funktion libusb_get_device_string (keine Ahnung was die genau tut), wird wohl kurzfristig nicht auf den Distros vorauszusetzen sein.
Ich bin nicht einmal sicher, ob die schon "akzeptiert" ist.

Kleiner Tipp am Rande: Du brauchst nicht Zeilennummern zählen um Versionen zu vergleichen.
Auf Github gibt es die "History". Dort kannst du den Commit mit Kommentar nachlesen.
https://github.com/libusb/libusb/commit ... ce939d8503

Dort gibt es auch noch einen rotes Kreuzchen ("Some checks were not successful").
Also bin ich nicht sicher, ob das schon reif ist.

[Garfield]

@theo: In habe zwei USB-Scanner. Weil es Probleme damit gibt, die Scannerliste zu aktualisieren, dachte ich, dass ich das über die libUSB lösen kann. Das hier war als erster Schritt gedacht, als nächstes möchte ich den Gerätetyp ermitteln. Scheint aber auch nicht so einfach zu sein. Vielleicht muss ich das über die VID/PID machen. Danach soll es mit der hotplug event notification weitergehen.

Kleiner Tipp am Rande: Du brauchst nicht Zeilennummern zählen um Versionen zu vergleichen.
Auf Github gibt es die "History". Dort kannst du den Commit mit Kommentar nachlesen.
https://github.com/libusb/libusb/commit ... ce939d8503

Kannte ich noch nicht.

[theo]

Aber warum machst du deswegen so einen Aufwand?
Ich meine, bis zu einem Punkt ist das bestimmt lustig und lehrreich, aber das braucht viel Zeit.

Tut's das nicht?

Code: Alles auswählen

uses process...
...
procedure TForm1.Button1Click(Sender: TObject);
var
  AProcess: TProcess;
begin
  AProcess := TProcess.Create(nil);
  AProcess.Executable := '/usr/bin/lsusb';
  AProcess.Options := AProcess.Options + [poWaitOnExit, poUsePipes];
  AProcess.Execute;
  Memo1.Lines.LoadFromStream(AProcess.Output);
  AProcess.Free;
end;   

[Garfield]

Wenn ich es mir ganz einfach machen will, reichen die VID/PID, welche mit der libusb ermittelt werden, schon aus. Dann müsste ich diese nur mit denen meiner Scanner abgleichen.

Meine Ausgangsfrage ist jedenfalls beantwortet.

[Mathias]

Würde die eine solche Ausgabe reichen:

Code: Alles auswählen

sudo ./project1
[sudo] Passwort für tux:       
Version: 1.0.27.11882

Gefundene USB-Geräte: 13
Device    0: VendorID =   7531   ProductID =      3   Klasse =    9
  Hersteller: Linux 6.8.0-87-generic xhci-hcd
  Produkt: xHCI Host Controller
  Seriennummer: 0000:03:00.0
Device    1: VendorID =   8457   ProductID =  13361   Klasse =    9
  Produkt: USB2.0 Hub
Device    2: VendorID =   7531   ProductID =      2   Klasse =    9
  Hersteller: Linux 6.8.0-87-generic xhci-hcd
  Produkt: xHCI Host Controller
  Seriennummer: 0000:03:00.0
Device    3: VendorID =   7531   ProductID =      3   Klasse =    9
  Hersteller: Linux 6.8.0-87-generic xhci-hcd
  Produkt: xHCI Host Controller
  Seriennummer: 0000:00:14.0
Device    4: VendorID =  32903   ProductID =     41   Klasse =  224
Device    5: VendorID =   1507   ProductID =   1544   Klasse =    9
  Produkt: USB2.0 Hub
Device    6: VendorID =   1133   ProductID =  49232   Klasse =    0
  Hersteller: Logitech
  Produkt: USB-PS/2 Optical Mouse
Device    7: VendorID =   1130   ProductID =     17   Klasse =    0
Device    8: VendorID =   6402   ProductID =  33537   Klasse =  239
  Hersteller: Generic
  Produkt: HD camera 
Device    9: VendorID =   1033   ProductID =     90   Klasse =    9
Device   10: VendorID =   1165   ProductID =  22274   Klasse =    0
  Hersteller: ITE Tech. Inc.
  Produkt: ITE Device
Device   11: VendorID =   1423   ProductID =  25442   Klasse =    0
  Hersteller: Generic
  Produkt: Flash Card Reader/Writer
  Seriennummer: 058F63626479
Device   12: VendorID =   7531   ProductID =      2   Klasse =    9
  Hersteller: Linux 6.8.0-87-generic xhci-hcd
  Produkt: xHCI Host Controller
  Seriennummer: 0000:00:14.0

Funktioniert leider nur als root.

[theo]

Ich verstehe immer noch nicht, warum man nicht einfach die Ausgabe von lsusb einliest.
Damit kann man sich den ganzen Ärger sparen, auch mit den Permissions etc.

Das ist nicht "pfui", das ist der einfachste, sicherste und wahrscheinlich sogar stabilste Weg.
Die Libs ändern sich ja immer mal wieder, wie wir gesehen haben. Die Ausgabe von lsusb eher nicht.

Unter Linux ist das ganz normal.

[Mathias]

Die Libs ändern sich ja immer mal wieder, wie wir gesehen haben. Die Ausgabe von lsusb eher nicht.

War nicht ursprünglich eher das Problem, das bei fpc-stable eine fehlerhafte Bindung dabei war ?
Und ich denke kaum, das sich libs immer wieder ändern, das wäre recht gefährlich. Stell die vor, die libgtk2 würde ändern, dann wäre vorbei mit Lazarus. Das betrifft aber nicht Ergänzungen von einer lib. GTK4 wächst auch immer wieder.
Anders sieht es natürlich aus, bei libs die beta sind, das hatte ich bei SDL3 gut gemerkt.

[theo]

@Mathias: Wie dem auch sei, das war nicht meine Frage.
Ich wollte wissen was dagegen spricht, einfach die Ausgabe von lsusb einzulesen und sich den ganzen Aufwand zu ersparen?