Legacy serial ports detection

Jakub Stachowski qbast at go2.pl
Tue Sep 7 15:10:10 PDT 2004


Dnia wtorek, 7 września 2004 20:08, David Zeuthen napisał:
> Hi,
>
> Sorry for the lag,
>
> On Sat, 2004-09-04 at 21:20 +0200, Jakub Stachowski wrote:
> > Hello,
> >
> > I have made patch for hald that adds support for legacy serial ports
> > (ttySx). For now it has one big problem: it merges also nonexistant
> > devices (for some strange reason sysfs always contains all 'potential'
> > serial ports - in most cases 8 of them - even on my laptop with one real
> > serial port). I can detect them via ioctl but have no idea how to remove
> > 'virtual' ones. I tried overloading class_device_in_gdl and removing
> > there but it hald sometimes crashed then. Important thing is that fake
> > port can be detected only by issuing ioctls over it. I have no more ideas
> > so maybe someone can help me with this.
>
> You should be able to do this in the pre_process method of the
> ClassDeviceHandler; just do this
>
>  hal_device_cancel (d);
>  hal_device_store_remove (hald_get_tdl (), d);
>  return;

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.

>
> if you want to cancel the device (the reason it needs to be done in
> pre_process is that we're waiting for e.g udev to name the device).
>
> > As I am completely new to hal some more answers will be appreciated:
> > 1) it would be good to detect modem - however it takes quite long, and it
> > would block hald, maybe separate thread?
>
> Uh, that would require locks and everything, probably something we
> eventually want to do; we have the same issue with probing storage
> devices insofar that it may take several seconds to spin up the drive.
>
> I'm not sure hald should do this automatically when starting up; see
> this mail for some thoughts about a Rescan() method:
>
>  http://freedesktop.org/pipermail/hal/2004-September/000871.html
>
> Presumably desktops and operating systems wants to invoke this for the
> "Detect Modem" control center thingy. But see below.
>
> > 2) the same goes for detecting printers on LPT (using ieee1284 detection)
> > - 3 seconds with my old lexmark 3200. Good think that it won't be
> > frequent - I suppose it could go like this:
> >  - try to detect on startup and remember if there was anything
> >  - on every tick: try to negotiate 'deviceid' mode - this will fail
> > without device
> >  - if last time deviceid mode failed and now succeeded do full detection.
> > This leads to next question:
> > What is best method to save detection result between ticks (per port).
> >  - if last time deviceid succeeded and now failed remove 'printer'
> > capability
> >
> > This scheme fill fail only if someone is capable of replacing driver
> > between two ticks.
> >
> > I suppose similar scheme could be used for detecting modems - using DSR
> > instead of deviceid mode to confirm that there is something to detect.
> >
> > 3) Legacy parallel port driver has its own class - 'ppdev' - and printer
> > discovery has to be made on it, not on 'lp' device. I don't know yet how
> > to merge "device" from ppdev class (used for printer discovery) into
> > device from 'lp' class - actual printer. And what to do if lp is merged
> > after ppdev. I have seen patch adding support for legacy lp - is it going
> > to be commited soon?
>
> Very specific questions; some rambling ahead:
>
> 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.

> 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!

> 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.
>
> 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?

>
> Cheers,
> David
>
> _______________________________________________
> hal mailing list
> hal at freedesktop.org
> http://freedesktop.org/mailman/listinfo/hal
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal



More information about the Hal mailing list