XGecu T48 T866 serial attached prommer not correctly recognized, how to set up udev?


I would like to use me USB prommer but it does not create a serial device. There is neither a /dev/ttyU* nor /dev/ttyA*

kernel: usb 1-14: new high-speed USB device number 54 using xhci_hcd
kernel: usb 1-14: New USB device found, idVendor=a466, idProduct=0a53, bcdDevice= 1.00
kernel: usb 1-14: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: usb 1-14: Product: XGecu T48 
kernel: usb 1-14: Manufacturer: XGecu.com
mtp-probe[240564]: checking bus 1, device 54: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-14"
mtp-probe[240564]: bus: 1, device: 54 was not an MTP device
plasmashell[240281]: 007c:fixme:wineusb:query_id Unhandled ID query type 0x5.
mtp-probe[240566]: checking bus 1, device 54: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-14"
mtp-probe[240566]: bus: 1, device: 54 was not an MTP device

On my old system I once added /etc/udev/rules.d/50-xgpro.rules

SUBSYSTEM=="usb", ATTR{idVendor}=="a466", ATTR{idProduct}=="0a53", GROUP="plugdev", MODE="0666"

which i found here and here

but first: I do not understand what it does and I do not find any device it created.
on my old system there is no ttyUSB0 either. And the log is equal, too. but it works?!

and second: it does not work on manjaro.

thank you very much

It detects when your device is plugged in and sets the owner so that everyone in the group plugdev can read and write to it.

It also sets the permissions so anyone can read and write to it.

On Arch based systems we don’t have plugdev, we have uucp instead. You should add yourself to that group.

# need to logout and back in for changes to take effect
sudo gpasswd -a $USER uucp  

udev sets the ownership of serial devices to uucp already, so you may not need the rule, but if you do then modify it like so.

`SUBSYSTEM=="usb", ATTR{idVendor}=="a466", ATTR{idProduct}=="0a53", GROUP="uucp", MODE="0666"`

The Arch wiki has moved to a new rule that doesn’t seem to need the user to be in the uucp group, but I’m not sure if it will work for you.


SUBSYSTEMS=="usb-serial", TAG+="uaccess"


Thank you very much for this great guide. But it still doesn’t work. :frowning:

But where does it put the device? I used these commands to find any device:

/dev$ find -type f|  xargs ls -l|grep rw-rw-rw
/dev$ find -type f|  xargs ls -l|grep plugdev
/dev$ find -type f|  xargs ls -l|grep uucp

on both old and new system and did not find anything. Should I search somewhere else?
Maybe my assumption to be a TTY device was wrong?

I tried the following:

  • I added myself to the uucp group and checked if this info is actually updated by issuing groups
  • I plugged the device and started the software from console using wine.
  • after that I updated the rules file with your changes
  • then udevadmi trigger
  • also unplugged and plugged again
  • ran the software again.

Do you have any idea?
Is there a way to find out which kernel module is responsible for this device? On the old system maybe?

I’ll try a logoff.

I know nothing about that device or about the windows software that is run through wine.
They do mention a linux software in one of your links, though.

Perhaps first verify what the system sees when you connect the device?

in a terminal, have the system log running so that you can see what the system is seeing:

journalctl -f

when I connect my phone, for example, this is what I see:

Jun 09 22:29:09 mint kernel: usb 3-1: new high-speed USB device number 3 using xhci_hcd
Jun 09 22:29:09 mint kernel: usb 3-1: New USB device found, idVendor=04e8, idProduct=6860, bcdDevice= 4.00
Jun 09 22:29:09 mint kernel: usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jun 09 22:29:09 mint kernel: usb 3-1: Product: SAMSUNG_Android

check that idVendor and idProduct actually match your device in your udev rule

Device files go in /dev…so you can ls /dev before and after plugging it in.

The find command doesn’t find many files (or the correct files) because of the -type f argument, and the pattern should be rwrwrw.

The find command is pointless anyway, ls -l /dev | grep uucp is all you need.

If you want to check subdirectories too, you can use ls -lR /dev | grep uucp, but you shouldn’t need to.

I don’t have a device to check with, but I would expect it to be a serial device. The manufacturer would know.

I do this.

sudo udevadm control --reload
sudo udevadm trigger

Are you using the windows software through wine? Or the linux version? I suggest trying the linux version, if you haven’t already.

Out of interest, what are you using this for, and is there another option for your use-case?

will not find what is wanted
since this device is probably of type c (a character device)
it’s pretty certain that it isn’t a type f (a regular file)

1 Like

Yep, that’s what I was alluding to, thanks for reminding me what type it is. :slight_smile:

Ouch. Yes, of course! Thanks for pointing that out!

Well, no. I found the file it created.

/dev/$ find|  xargs ls -l|grep crw-rw-rw|grep uucp
crw-rw-rw-+  1 root uucp    189,    18 10. Jun 13:09 ./bus/usb/001/019

ls would not have shown it which directory it is.

Windows binary through wine. There is no other software. Worked just fine on Kubuntu.

I am using this for programming the Atmega328 and the occasional eprom here and there. It’s a prommer.

I tried to find a log file, but cannot find any.

I think I have to go to the WINE forum. I need a wrapper DLL named setupapi.dll. But as soon as I place it into the dir, it does not start any more.

setupapi.dll: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=1694299ee3a39191020a2a3b1fff00738ddd84eb, not stripped

maybe I need 64 bit? or wine-386 binaries?

In case someone else got this problem, here is the source of the usb wrapper:

you must be member of the uucp-group to get access for serial communication. add yourself to the group uucp, reboot, check and report

usermod -aG uucp $USER

What about this? It’s from the 2nd link you posted, under “native linux software (not tested yet)”. @Nachlese already mentioned it.

Experimental support for Xgecu T48 programmer

1 Like

Opps. Overlooked it.
wow. works out of the box.
thank you
I mark your answer as the solution, to mark the thread as solved.
but I will still try to make the other software work. just less priority. :slight_smile:

1 Like

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.