Legacy serial ports detection

[David Zeuthen]

On Wed, 2004-09-08 at 00:10 +0200, Jakub Stachowski wrote:
> I tried that but then hald crashes. It seems not to care about device being 
> cancelled and removed and just processed it further.
> 
> And I just remembered: coldplug doesn't seem to work - if serial module 
> (8520.ko) was loaded before starting hald serial devices are not seen. The 
> same problem is with input devices - i have to unload module and load it 
> again.
> 

Right, I think I broke that when I rewrote some of the coldplug code;
probably because the coldplug code doesn't care about class devices
without the device symlink; will look into it.

> > Maybe hal shouldn't care too much about legacy ports, perhaps all we
> > should do is to show that they are available? (e.g. exactly one serial
> > port on your laptop and zero on my powerbook).
> >
> 
> I have also desktop computer with parallel printer and modem (something 
> between dial-up and DSL - i know that it is strange) connected to serial 
> port.
> 
> Of course not caring about legacy devices is one way of solving problem, but 
> it also makes hal less usable.
> 

Not sure; it's basically just how we choose to architecture stuff; what
to offload to higher layers and what to handle at the hal daemon layer.

(hal is really a bad name btw, pnpkit, DeviceKit or something less
confusing might be a better name :-)

There's been discussion of doing abstraction stuff above the hal daemon
level; I'll be working on a libhal-storage library pretty soon.

> > Something more specific like gnome-system-tools, kppp or NetworkManager
> > should probably use this to help the user detect modems and some of the
> 
> That would be much better - for now kppp presents lists of any possible 
> devices - ttySx, ttyACMx, ttylx, rfcommx, ttySLx - and i have only two serial 
> ports on this computer!
> 

Yeah, most desktop apps today (even new ones) even have the nerve to use
UNIX-jargon like eth0, ppp0; ask user for impl details like device file
name and so forth. Personally, I think don't think that is good UI.

> > existing cups UI software should ask hal for parallel ports to detect
> > printers? It seems more right to me.. Don't know..
> 
> It seems very right - cups is perfect example of program that could benefit 
> from hal. You connect the printer, hal sends notify, cups checks manufacturer 
> and model and if have matching driver just adds it to list of available 
> printers.

This Just Work(tm) (barring funky printers like the HP1000 issue
reported last week) with USB printers but it of course requires some
integration with the operating system and pieces like CUPS etc. John
Palmieri have done this for Fedora; I don't own a printer but I've been
told it works great.

But for parallel port printers there is AFAIK no reliable way to get
notified for device insertion/removal or am I wrong? If there is, great,
let's do it if it's totally reliable.

Hence the suggestion to just let hal export 'here's IEEE1284 parallel
port' or 'here's a 16550S serial port' (and we make sure it exists and
is just not a logical interface like ttyS0-ttyS7). 

Existing GUI already has the 'detect printer' button (like system-
config-printer on Fedora) and 'detect camera' (like gthumb) button for
those legacy ports; there's really little we can and should be doing
about that at the hal daemon level. 

Anyway, that's my current position; maybe it does make sense to let does
apps like system-config-printer just call Rescan() on parallel port
device object when the 'detect printer' button is pressed and magically
this device object will receive the capability 'printer' if there indeed
is a powered-up printer attached? Perhaps the same for modems? Not
sure..

> >
> > Btw, something like USB modems should probably be autodetected much like
> > we autodetect USB printers; need to buy an USB modem I guess :-)
> 
> So there is special ioctl for that? Or just using usb ids?
> 

Well, I don't own a USB modem yet. I suspect it will basically just be a
tty device that points to the appropriate USB interface; hence when
merging the tty class device we can check the class of the USB
interface. But I'm guessing now; it may even differ from driver to
driver.

Cheers,
David

_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal