No /dev/bus/usb/ in Lucid Puppy
One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?
Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.
Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.
Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.
Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
TBH, I wouldn't think so. Although I can't say for sure with the newer stuff; my old SX218 must be getting on for 9-10 years old now. Too old for them to bother with, I should imagine!ahoppin wrote:One more question, Mike -- do you know for sure that the Epson Linux package doesn't phone home to Epson and update your printer/scanner's firmware?
Not that it's likely to be a problem with a dedicated scanner, but I ask because some folks who have the MFP machines are avoiding Epson firmware updates. IIRC a while back Epson started adding firmware functions to make the printers reject third-party ink.
Don't get me started on manufacturers that treat their users like potential enemies, to be spied on, and punished if they do something that might hurt the manufacturers' profits.
(I'm in Tahr 606 ATM, my most recent addition to the kennels (just a couple of months back), and less than 5 minutes ago I printed a document off, using third-party ink.....)
(*shrug*)
And your scanner is, by your own admission, quite an old one. D'you know, what you say about this is the first I've heard of it.....but with the way the price of OEM ink is going, it's hardly surprising, I suppose.
I somehow doubt you and I will have any problems with that one. Especially not your scanner; they don't use ink, so I can't see what Epson would stand to gain from such an excercise.....
Mike.
Could be that you're right, that your printer is old enough that Epson has mostly forgotten about it. You never know though...
If you search the web you'll find plenty of info about the ink wars. HP was the most recent "bad guy," but Epson has been named too.
It's an older discussion, but try this one as an example:
https://www.printerknowledge.com/thread ... ning.6614/
or https://v.gd/KIjECw
It seems that keeping third-party ink working with many inkjet printers, including Epsons, is a cat and mouse game. The Chinese chip techs reverse-engineer the factory ink cart chips, and sell clones to the refillers. Recycled ink carts using those clone chips then work -- until the cat (the printer maker) pushes a new firmware update to the printer to block them. Then the updated printer gripes that your carts "can't be recognized," and the Chinese mice go to work again.
I think there are now some legal restrictions on this practice of limiting third-party ink use in the EU. However, here in the US, the laws are usually not as strongly pro-consumer.
For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.
Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.
To bring this marginally back on topic, I found this thread on the board:
http://murga-linux.com/puppy/viewtopic.php?t=61885
It seems that rcrsn51 has written a utility that converts Epson's proprietary Linux printer drivers to native Puppy .pet packages, a great idea. I would hope that his utility would install just what's necessary for printing, omitting any spyware or updaters, but I can't tell for sure from the thread.
If you search the web you'll find plenty of info about the ink wars. HP was the most recent "bad guy," but Epson has been named too.
It's an older discussion, but try this one as an example:
https://www.printerknowledge.com/thread ... ning.6614/
or https://v.gd/KIjECw
It seems that keeping third-party ink working with many inkjet printers, including Epsons, is a cat and mouse game. The Chinese chip techs reverse-engineer the factory ink cart chips, and sell clones to the refillers. Recycled ink carts using those clone chips then work -- until the cat (the printer maker) pushes a new firmware update to the printer to block them. Then the updated printer gripes that your carts "can't be recognized," and the Chinese mice go to work again.
I think there are now some legal restrictions on this practice of limiting third-party ink use in the EU. However, here in the US, the laws are usually not as strongly pro-consumer.
For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.
Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.
To bring this marginally back on topic, I found this thread on the board:
http://murga-linux.com/puppy/viewtopic.php?t=61885
It seems that rcrsn51 has written a utility that converts Epson's proprietary Linux printer drivers to native Puppy .pet packages, a great idea. I would hope that his utility would install just what's necessary for printing, omitting any spyware or updaters, but I can't tell for sure from the thread.
/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.
I'm pretty sure that when udev (the usb hotplug daemon, if I understand it right) sees a USB device plugged in, it creates or updates the device files in /dev with reference to configuration files in /etc/udev/rules.d. I suppose those rules may read the contents of /etc/group (among other files), but I don't know for sure.
In the specific context of USB scanners and sane, in most cases you want the rules to create scanner device files in /dev so that they're rw for the scanner or lp group. Then if spot (or other regular non-root user) is a member of the scanner or lp group, the non-root user can (if all goes well) use xsane.
Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.
Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.
Now, though, I have a version of xsane that doesn't complain about being run as root, so my problem is effectively solved.
But I remain curious about USB in Puppy. If you want to join me in experimenting with the different ways these different pups handle USB devices, you can download the iso files back to version 2.16 from http://distro.ibiblio.org/puppylinux/
I'm pretty sure that when udev (the usb hotplug daemon, if I understand it right) sees a USB device plugged in, it creates or updates the device files in /dev with reference to configuration files in /etc/udev/rules.d. I suppose those rules may read the contents of /etc/group (among other files), but I don't know for sure.
In the specific context of USB scanners and sane, in most cases you want the rules to create scanner device files in /dev so that they're rw for the scanner or lp group. Then if spot (or other regular non-root user) is a member of the scanner or lp group, the non-root user can (if all goes well) use xsane.
Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.
Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.
Now, though, I have a version of xsane that doesn't complain about being run as root, so my problem is effectively solved.
But I remain curious about USB in Puppy. If you want to join me in experimenting with the different ways these different pups handle USB devices, you can download the iso files back to version 2.16 from http://distro.ibiblio.org/puppylinux/
I think you are assuming that the reason Spot can't scan is because it doesn't have permission to access a device port. It may be that it does not have permission to access a file in /etc (eg /etc/sane.d) or maybe that it does not have permission to access a newly plugged device like a scanner (as is the norm for non root users wanting to access a newly plugged device) - in which case part of the answer may be to ensure that Spot is added to /etc/group as having access to scanner devices.ahoppin wrote:/etc/group and /etc/sane.d/epson2.conf are static files, so AFAIK there's no way they can or will change on hotplug events.
But you also said that all of the files in /dev were already accessible to Spot. I probably misunderstood, but I never grasped why you thought it was successful to chmod /dev files, while also saying "There's no need to change the permissions of /dev, it's already 755 (rwxr-xr-x), so it's searchable by anyone.Or you can just cheat and tell udev to make the device files rw for everyone, and not worry about the users' group membership.
Or do what I did before, and use a shell script to chmod them after they're created. As I said way back in this thread, that worked great for SCSI device files in Lucid 5.2.5, but I couldn't make it work for USB in that version. I still don't know why not.
The usbdev* files are at the first level under /dev, so there are no directories that would need to be changed."
Surely it can't be both ways? Either all /dev files are available to Spot or they are not. If all of the /dev files and /etc fles are accessible to Spot but you still can't access the backend then the problem must be somewhere else?
Hotplug changed from Puppy to Puppy and I guess that changes the specifics of the usb detection - sometimes there are conflicts with kernel drivers apparently.But I remain curious about USB in Puppy
I think Bigpup summed it up though - Spot was intended for internet protections and as a result it will be a longwinded bughunt to work out which file is preventing Spot from accessing the specific hardware resource.
Sorry I couldn't be of any help
cheers!
- Mike Walsh
- Posts: 6351
- Joined: Sat 28 Jun 2014, 12:42
- Location: King's Lynn, UK.
Hi, ahoppin.
I'll stick with what works for me, thank you very much..! And, er....thanks for the heads-up on Epson pulling the same stunt as HP; I wasn't aware of that, I must admit. (My practice of using the same set of drivers indefinitely probably shielded me from that one...)
Mike.
Which is why I keep using the same set of drivers that were current at the time when I first bought the SX218 several years ago. They still install, they still give me full functionality, I can still use 3rd-party ink.....where's the point in updating them? Especially if these firmware updates are being pushed out via the updated driver packages?ahoppin wrote:For Epsons specifically, it appears that the firmware updater is built into the Windows (and presumably Mac) drivers. That's why I'm suspicious that Epson might also added this functionality to their Linux driver, at least to the printing driver.
Again, it's probably not a concern for standalone scanners, but folks with MFPs and standalone printers, at least relatively new ones, will probably want to pay attention.
I'll stick with what works for me, thank you very much..! And, er....thanks for the heads-up on Epson pulling the same stunt as HP; I wasn't aware of that, I must admit. (My practice of using the same set of drivers indefinitely probably shielded me from that one...)
Mike.
> It may be that it does not have permission to access a file in
> /etc (eg /etc/sane.d)
I checked that when you mentioned it before, and it didn't fix the problem. Good analysis though.
> or maybe that it does not have permission
> to access a newly plugged device like a scanner (as is the norm for
> non root users wanting to access a newly plugged device) - in which
> case part of the answer may be to ensure that Spot is added
> to /etc/group as having access to scanner devices.
That would probably work, if the SANE udev rules were in place the way they seem to be for other distros. Search around or look at some of the forums I linked to before, and you'll see these scanner group rules quoted.
But you won't see them in Puppy's /etc/udev/rules.d.
Nor is there a scanner group in /etc/group.
My guess is that BK and the Puppy programming team didn't include them because normally all Puppy users run as root, so permissions don't matter for them.
I think the above idea probably would work if you created the scanner group, made spot a member of it, and manually added all the necessary udev rules. I haven't tried it, though.
> I never grasped why you thought it was successful to chmod /dev
> files, while also saying "There's no need to change the permissions of
> /dev...
>
> Surely it can't be both ways? Either all /dev files are available to
> Spot or they are not.
"Available" doesn't necessarily mean "usable."
Since /dev is mode 755 (rwxr-xr-x), it's *searchable* by anyone. Spot's programs, in this case xsane, scanimage, etc, can thus find the files they need in /dev.
But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.
So both conditions have to exist. Sorry if that wasn't clear.
> /etc (eg /etc/sane.d)
I checked that when you mentioned it before, and it didn't fix the problem. Good analysis though.
> or maybe that it does not have permission
> to access a newly plugged device like a scanner (as is the norm for
> non root users wanting to access a newly plugged device) - in which
> case part of the answer may be to ensure that Spot is added
> to /etc/group as having access to scanner devices.
That would probably work, if the SANE udev rules were in place the way they seem to be for other distros. Search around or look at some of the forums I linked to before, and you'll see these scanner group rules quoted.
But you won't see them in Puppy's /etc/udev/rules.d.
Nor is there a scanner group in /etc/group.
My guess is that BK and the Puppy programming team didn't include them because normally all Puppy users run as root, so permissions don't matter for them.
I think the above idea probably would work if you created the scanner group, made spot a member of it, and manually added all the necessary udev rules. I haven't tried it, though.
> I never grasped why you thought it was successful to chmod /dev
> files, while also saying "There's no need to change the permissions of
> /dev...
>
> Surely it can't be both ways? Either all /dev files are available to
> Spot or they are not.
"Available" doesn't necessarily mean "usable."
Since /dev is mode 755 (rwxr-xr-x), it's *searchable* by anyone. Spot's programs, in this case xsane, scanimage, etc, can thus find the files they need in /dev.
But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.
So both conditions have to exist. Sorry if that wasn't clear.
No - it's just my ignorance in playahoppin wrote:But just *finding* the device files isn't enough. Spot's program (SANE) also has to be able to open them for reading and writing. So the files in /dev have to either be owned or in the same group as Spot, or they have to be read/write for anyone.
So both conditions have to exist. Sorry if that wasn't clear.
I thought that "chown"ing was the same thing as offering "all permissions".
What I meant was - that if you give Spot total control of everything in /dev and /etc (recursively) it would show whether or not that is where the "resource denied" bottleneck was.
I just figured that the "bus" directories (or their alternatives) would most likely be in /etc or /dev. Unless they exist only in /proc - which is possible depending on the structure of the kernel modules.
Of course - even if setting full Spot permissions for /etc and /dev was successful - it would not pin down specifically where the problem lay, but I just hoped it might remove the roadblocks and provide somewhere to focus the lens.
Good luck!