diana_coman: for the curious there are in fact 2 prolific-stamped documents describing pl2303 and pl2303x; pl2303x seems to be a sort of upgrade to 64bits but why couldn't it be properly identified as distinct I don't know ☟︎☟︎

diana_coman: n it is "new" pl2303x; *newer* linux will work because basically they have been adapted to the idiocy so they check and adapt

diana_coman: http://btcbase.org/log/2017-11-10#1735788 <- I don't really see how it is linux' fault here; so prolific used to make the pl2303 and old linux worked fine with it and still does; THEN they (or chinese cheap copies dunno) made a DIFFERENT thing pl2303x that has however the same serial id and everything so you can't distinguish between them before plugging them in pretty much; and so yes, old linux won't work because it sees it as pl2303 whe ☝︎

diana_coman: asciilifeform, one can patch the kernel to work with both pl2303 AND pl2303x; but otherwise yes, obv is obv, either actual serial port or otherwise finding a combo that works

diana_coman: asciilifeform, well, for various definitions of resolve; I'm satisfied that problem was as identified i.e. pl2303x vs pl2303

diana_coman: "the pl2303x can be distinguished from a pl2303 by checking bMaxPacketSize0 for device using lsusb -v -d 067b:2303; if bmaxpacketsize0 is 64 you probably have pl2303x"

diana_coman: and so this one seems to be pl2303x

diana_coman: on the possibly enraging more digging turned out a known shit -difference between pl2303 and pl2303x ☟︎