[patch] Re: HAL and hotplugging

[Dustin Spicuzza]

>> Can we get rid of that whole block, please? Why check for certain input.* 
>> capabilities when input.x11_driver should be totally enough for deciding if 
>> we can hotplug this or not (just exit and don't print an error when 
>> input.x11_driver is not set). That way we can hotplug devices that are not 
>> input.keys or input.mouse or input.touchpad, like a joystick with the 
>> joystick driver. 
>>     
I didn't add it, it was already there... the only reason you see it in 
the patch is because originally one of the variables was named 'props', 
and it didn't make any sense given my new set of code... so I renamed it 
to 'capabilities'. I agree with Sascha/Daniel though, I'll remove it.

> When we hit a platform that doesn't have it, we can steal the BSD libc's
> implementation.  Until then, I wouldn't really worry -- I guess, just
> add a configure check that looks for it and bombs out if not.
>   
Ok... I'm not 100% sure how to do that. I'll copy something from somewhere.
>   
>> -    DebugF("[config/hal] removing device %s\n", dev->name);
>> +    /* this isn't an error, but the user should see this */
>> +    ErrorF("[config/hal] removing device %s\n", dev->name);
>>     
>
> Hmm, do they really need the log filled with messages every time they
> plug or unplug a device?
>   
Yes, they do -- otherwise you can't be sure if the HAL layer is actually 
doing anything (one of the problems I had when originally working with 
this). I agree though, most users won't want to  see it in normal usage 
-- how do you specify that the message only be shown when the logverbose 
level is high? I tried using xf86Msg, but had a link error and wasn't 
able to figure out how to fix it.
>
> Err, assuming you remove the capabilities check, this will trigger every
> single time you hotplug any device that isn't an input device, e.g. a
> thumbdrive, camera, external media, etc, etc.
>   
Same problem as above. The user should be able to find out when its 
trying if they're having issues. Especially given the extreme lack of 
documentation on a lot of this (or outdated documentation).
>
> Yeah.  Given that there are so few hotplug-capable drivers, though
> (evdev, evtouch, wacom, ... ?), I was hoping that we'd just be able to
> change the drivers to take the slightly more explicit 'path'.
>   
I'm confused... since drivers don't implement hotplug, and its simply a 
matter of loading/unloading the driver... all drivers implement 
loading/unloading, correct? Maybe migrating them to change device to 
path would be a good idea, (what about DevicePath instead?). Its also 
not documented AFAIK, so nobody knows to use path anyways.
> Why not just fold all the above code into the iterator here, so we cut
> down on round trips?
>
>   
Probably a good idea. I'll do that. Really, I think the xkb options are 
rather verbose anyways, and we should depreciate them / remove them, 
since x11_options provides the same exact functionality. Though, I know 
people are using it, so thats why I didn't want to outright remove them.
> Looks pretty much good other than the above comments.
>   
Ok... I'll rework all of that (basically, redo the entire function, ha), 
and post a better patch later this afternoon -- after I can get some 
answers about the above questions. I'll be in #xorg-devel later too 
(virtuald) if anyone has further thoughts, gonna do some stuff first.

Dustin

-- 
Innovation is just a problem away