Skip to contentSkip to conversation

input hotplug support

PATCH In review Andrey Borzenkov 3 participants 6 messages Aug 1, 2003 – Oct 29, 2003

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 input hotplug support

this adds input agent and coldplug rc script. It relies on patch for module-init-tools that gnerates input handlers map table being posted to lkml as well.

input agent loads input handler in respond to input subsystem request. It is currently purely table-driven, no attempt to provide for any static list or like was done, it needs some operational experience.

static coldplug rc script is intended to load input handlers for any built-in input drivers, like e.g. psmouse (if you built it in). Currently it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently support for it in input susbsystem is incomplete at best.

It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not needed anymore.

Patch is against 2003_05_01 version of hotplug. Comments appreciated.

-andrey

#1 lore raw
Quoted 13 lines · Andrey Borzenkov

this adds input agent and coldplug rc script. It relies on patch for module-init-tools that gnerates input handlers map table being posted to lkml as well.

input agent loads input handler in respond to input subsystem request. It is currently purely table-driven, no attempt to provide for any static list or like was done, it needs some operational experience.

static coldplug rc script is intended to load input handlers for any built-in input drivers, like e.g. psmouse (if you built it in). Currently it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently support for it in input susbsystem is incomplete at best.

Quoted 4 lines

It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not needed anymore.

Patch is against 2003_05_01 version of hotplug. Comments appreciated.

Can you send it not compressed so we have a chance to read it?

thanks,

greg k-h

-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#2 lore raw
In reply to Andrey Borzenkov
Quoted 14 lines · Greg KH
Quoted 13 lines · Andrey Borzenkov

this adds input agent and coldplug rc script. It relies on patch for module-init-tools that gnerates input handlers map table being posted to lkml as well.

input agent loads input handler in respond to input subsystem request. It is currently purely table-driven, no attempt to provide for any static list or like was done, it needs some operational experience.

static coldplug rc script is intended to load input handlers for any built-in input drivers, like e.g. psmouse (if you built it in). Currently it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently support for it in input susbsystem is incomplete at best.

Quoted 7 lines
Quoted 4 lines

It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not needed anymore.

Patch is against 2003_05_01 version of hotplug. Comments appreciated.

Can you send it not compressed so we have a chance to read it?

sorry.

plain text attached.

-andrey

etc/hotplug/input.agent renamed from etc/hotplug/input.agent.input +316 -0
@@ -0,0 +1,316 @@
+#!/bin/bash
+#
+# input-specific hotplug policy agent.
+#
+# This should handle 2.6.* input hotplugging,
+# with a consistent framework for adding device and driver
+# specific handling.
+#
+# Normally, adding a input device will modprobe handler(s) for
+# this device.
+#
+# Kernel input hotplug params include (not all of them may be available):
+#	
+#	ACTION=%s [add or remove]
+#	PRODUCT=%x/%x/%x/%x
+#	NAME=%s
+#	PHYS=%s
+#	EV=%lx
+#	KEY=%lx %lx ...
+#	REL=%lx
+#	ABS=%lx %lx ...
+#	MSC=%lx
+#	LED=%lx
+#	SND=%lx
+#	FF=%lx %lx ...
+#
+# HISTORY:
+#
+# 30-Jul-2003	initial version
+#
+
+cd /etc/hotplug
+. hotplug.functions
+# DEBUG=yes export DEBUG
+
+# generated by module-init-tools
+MAP_CURRENT=$MODULE_DIR/modules.inputmap
+
+# accumulates list of modules we may care about
+DRIVERS=""
+
+if [ "$ACTION" = "" ]; then
+    mesg Bad INPUT agent invocation, no action
+    exit 1
+fi
+
+# we can't "unset IFS" on bash1, so save a copy
+DEFAULT_IFS="$IFS"
+
+#
+# Each modules.inputmap format line corresponds to one entry in a
+# MODULE_DEVICE_TABLE(input,...) declaration in a kernel file.
+#
+declare -i matchBits=0
+declare -i i_bustype=0 i_vendor=0 i_product=0 i_version=0
+declare -i i_evBits=0
+declare i_keyBits i_relBits i_absBits i_mscBits i_ledBits i_sndBits i_ffBits
+
+input_join_words ()
+{
+    declare name=$1 array=$2 tmp
+    if [ "$array" = '' ]; then
+	return
+    fi
+
+    set $array
+
+    tmp=$1
+    shift
+    while [ "$#" -gt 0 ]; do
+	tmp="$tmp:$1"
+	shift
+    done
+
+    eval "$name=\"$tmp\""
+}
+
+input_convert_vars ()
+{
+    if [ "$PRODUCT" != "" ]; then
+	IFS=/
+	set $PRODUCT ''
+	IFS="$DEFAULT_IFS"
+	i_bustype=0x$1
+	i_vendor=0x$2
+	i_product=0x$3
+	i_version=0x$4
+    fi
+
+    if [ "$EV" != "" ]; then
+	i_evBits=0x$EV
+    fi
+
+    input_join_words i_keyBits "$KEY"
+    input_join_words i_relBits "$REL"
+    input_join_words i_absBits "$ABS"
+    input_join_words i_mscBits "$MSC"
+    input_join_words i_ledBits "$LED"
+    input_join_words i_sndBits "$SND"
+    input_join_words i_ffBits  "$FF"
+}
+
+declare -i INPUT_DEVICE_ID_MATCH_BUS=1
+declare -i INPUT_DEVICE_ID_MATCH_VENDOR=2
+declare -i INPUT_DEVICE_ID_MATCH_PRODUCT=4
+declare -i INPUT_DEVICE_ID_MATCH_VERSION=8
+declare -i INPUT_DEVICE_ID_MATCH_EVBIT=0x010
+declare -i INPUT_DEVICE_ID_MATCH_KEYBIT=0x020
+declare -i INPUT_DEVICE_ID_MATCH_RELBIT=0x040
+declare -i INPUT_DEVICE_ID_MATCH_ABSBIT=0x080
+declare -i INPUT_DEVICE_ID_MATCH_MSCBIT=0x100
+declare -i INPUT_DEVICE_ID_MATCH_LEDBIT=0x200
+declare -i INPUT_DEVICE_ID_MATCH_SNDBIT=0x400
+declare -i INPUT_DEVICE_ID_MATCH_FFBIT=0x800
+
+
+input_match_bits ()
+{
+    declare mod_bits=$1 dev_bits=$2
+    declare -i mword dword
+
+    mword=0x${mod_bits##*:}
+    dword=0x${dev_bits##*:}
+
+    while true; do
+	if [ $(( $mword & $dword != $mword )) -eq 1 ]; then
+	    return 1
+	fi
+
+	mod_bits=${mod_bits%:*}
+	dev_bits=${dev_bits%:*}
+
+	case "$mod_bits-$dev_bits" in
+	    *:*-*:* )
+		: continue
+	    ;;
+	    *:*-*|*-*:* )
+		return 0
+	    ;;
+	    * )
+		return 1
+	    ;;
+	esac
+    done
+}
+
+#
+# stdin is "modules.inputmap" syntax
+# on return, all matching modules were added to $DRIVERS
+#
+input_map_modules ()
+{
+    local line module
+    declare -i matchBits
+    declare -i bustype vendor product version
+    declare -i evBits driverInfo 
+    declare relBits mscBits ledBits sndBitskeyBits absBits ffBits
+
+    while read line
+    do
+        # comments are lines that start with "#" ...
+	# be careful, they still get parsed by bash!
+	case "$line" in
+	\#*) continue ;;
+	esac
+
+	set $line
+
+	module="$1"
+	matchBits="$2"
+
+	bustype="$3"
+	vendor="$4"
+	product="$5"
+	product="$6"
+
+	evBits="$7"
+	keyBits="$8"
+	relBits="$9"
+
+	shift 9
+	absBits="$1"
+	cbsBits="$2"
+	ledBits="$3"
+	sndBits="$4"
+	ffBits="$5"
+	driverInfo="$6"
+
+	: checkmatch $module
+
+	: bustype $bustype $i_bustype
+        if [ $INPUT_DEVICE_ID_MATCH_BUS -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_BUS )) ] && 
+	   [ $bustype -ne $i_bustype ]; then
+	    continue
+	fi
+
+	: vendor $vendor $i_vendor
+        if [ $INPUT_DEVICE_ID_MATCH_VENDOR -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_VENDOR )) ] && 
+	   [ $vendor -ne $i_vendor ]; then
+	    continue
+	fi
+
+	: product $product $i_product
+        if [ $INPUT_DEVICE_ID_MATCH_PRODUCT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_PRODUCT )) ] && 
+	   [ $product -ne $i_product ]; then
+	    continue
+	fi
+
+	# version i_version $i_version < version $version
+        if [ $INPUT_DEVICE_ID_MATCH_VERSION -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_VERSION )) ] && 
+	   [ $version -ge $i_version ]; then
+	    continue
+	fi
+
+	: evBits $evBits $i_evBits
+        if [ $INPUT_DEVICE_ID_MATCH_EVBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_EVBIT )) ] && 
+	   [ $evBits -ne $(( $evBits & $i_evBits)) ]; then
+	    continue
+	fi
+	: keyBits $keyBits $i_keyBits
+        if [ $INPUT_DEVICE_ID_MATCH_KEYBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_KEYBIT )) ] && 
+	   input_match_bits "$keyBits" "$i_keyBits"; then
+	    continue
+	fi
+	: relBits $relBits $i_relBits
+        if [ $INPUT_DEVICE_ID_MATCH_RELBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_RELBIT )) ] && 
+	   [ $relBits -ne $(( $relBits & $i_relBits)) ]; then
+	    continue
+	fi
+
+	: absBits $absBits $i_absBits
+        if [ $INPUT_DEVICE_ID_MATCH_ABSBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_ABSBIT )) ] && 
+	   input_match_bits "$absBits" "$i_absBits"; then
+	    continue
+	fi
+
+	: mscBits $mscBits $i_mscBits
+        if [ $INPUT_DEVICE_ID_MATCH_MSCBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_MSCBIT )) ] && 
+	   [ $mscBits -ne $(( $mscBits & $i_mscBits)) ]; then
+	    continue
+	fi
+
+	: ledBits $ledBits $_ledBits
+        if [ $INPUT_DEVICE_ID_MATCH_LEDBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_LEDBIT )) ] && 
+	   input_match_bits "$ledBits" "$i_ledBits"; then
+	    continue
+	fi
+
+	: sndBits $sndBits $i_sndBits
+        if [ $INPUT_DEVICE_ID_MATCH_SNDBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_SNDBIT )) ] && 
+	   [ $sndBits -ne $(( $sndBits & $i_sndBits)) ]; then
+	    continue
+	fi
+
+	: ffBits $ffBits $i_ffBits
+        if [ $INPUT_DEVICE_ID_MATCH_FFBIT -eq $(( $matchBits & $INPUT_DEVICE_ID_MATCH_FFBIT )) ] && 
+	   input_match_bits "$ffBits" "$i_ffBits"; then
+	    continue
+	fi
+
+	: driverInfo $driverInfo
+	if [ $matchBits -eq 0 -a $driverInfo -eq 0 ]; then
+		continue
+	fi
+
+	# It was a match!
+	case " $DRIVERS " in
+	    *" $module "* )
+		: already found
+	    ;;
+	    * )
+		DRIVERS="$module $DRIVERS"
+	    ;;
+	esac
+	: drivers $DRIVERS
+    done
+}
+
+#
+# What to do with this INPUT hotplug event?
+#
+case $ACTION in
+
+add)
+
+    input_convert_vars
+
+    FOUND=false
+    LABEL="INPUT product $PRODUCT"
+
+    if [ -r $MAP_CURRENT ]; then
+	load_drivers input $MAP_CURRENT "$LABEL"
+    fi
+
+    if [ "$DRIVERS" != "" ]; then
+	FOUND=true
+    fi
+
+    if [ "$FOUND" = "false" ]; then
+	mesg "... no modules for $LABEL"
+	exit 2
+    fi
+
+    ;;
+
+remove)
+    : nothing so far
+
+    ;;
+
+*)
+    debug_mesg INPUT $ACTION event not supported
+    exit 1
+    ;;
+
+esac
etc/hotplug/input.rc renamed from etc/hotplug/input.rc.input +147 -0

147 lines not on this page · raw message

etc/hotplug/usb.agent renamed from etc/hotplug/usb.agent.input +14 -6
@@ -397,12 +397,20 @@
 
     # cope with special driver module configurations
     # (mostly HID devices, until we have an input.agent)
-    if [ -r $MAP_HANDMAP ]; then
-    	load_drivers usb $MAP_HANDMAP "$LABEL"
-	if [ "$DRIVERS" != "" ]; then
-	    FOUND=true
-	fi
-    fi
+    # not needed on 2.6 - they are loaded by hotplug
+    case "$KERNEL" in
+	2.6.* )
+	    : nothing
+	;;
+	* )
+	    if [ -r $MAP_HANDMAP ]; then
+		load_drivers usb $MAP_HANDMAP "$LABEL"
+		if [ "$DRIVERS" != "" ]; then
+		    FOUND=true
+		fi
+	    fi
+	;;
+    esac
 
     # some devices have user-mode drivers (no kernel module, but config)
     # or specialized user-mode setup helpers 
#3 lore raw
In reply to Andrey Borzenkov
Quoted 18 lines · Andrey Borzenkov
Quoted 17 lines · Greg KH
Quoted 16 lines · Andrey Borzenkov

this adds input agent and coldplug rc script. It relies on patch for module-init-tools that gnerates input handlers map table being posted to lkml as well.

input agent loads input handler in respond to input subsystem request. It is currently purely table-driven, no attempt to provide for any static list or like was done, it needs some operational experience.

static coldplug rc script is intended to load input handlers for any built-in input drivers, like e.g. psmouse (if you built it in). Currently it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently support for it in input susbsystem is incomplete at best.

It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not needed anymore.

Quoted 7 lines
Quoted 3 lines
Quoted 1 line

Patch is against 2003_05_01 version of hotplug. Comments appreciated.

Can you send it not compressed so we have a chance to read it?

sorry.

plain text attached.

Thanks, I've applied this patch. Did your module-init-tools patch make it into that package too?

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#4 lore raw
In reply to Andrey Borzenkov
Quoted 23 lines · Greg KH
Quoted 22 lines · Andrey Borzenkov
Quoted 21 lines · Greg KH
Quoted 19 lines · Andrey Borzenkov

this adds input agent and coldplug rc script. It relies on patch for module-init-tools that gnerates input handlers map table being posted to lkml as well.

input agent loads input handler in respond to input subsystem request. It is currently purely table-driven, no attempt to provide for any static list or like was done, it needs some operational experience.

static coldplug rc script is intended to load input handlers for any built-in input drivers, like e.g. psmouse (if you built it in). Currently it does it by parsing /proc/bus/input/devices, I'd like to use sysfs but apparently support for it in input susbsystem is incomplete at best.

It also modifies usb.agent to not consult usb.handmap on 2.6, as it is not needed anymore.

Patch is against 2003_05_01 version of hotplug. Comments appreciated.

Quoted 9 lines
Quoted 5 lines
Quoted 1 line

Can you send it not compressed so we have a chance to read it?

sorry.

plain text attached.

Thanks, I've applied this patch. Did your module-init-tools patch make it into that package too?

No, Rusty was against it. You should have received those mails as well (you were on Cc at least), subject was

"module-init-tools - input devices id support"

If you do not have them I can forward or they are on lkml as well, sorry do not have pointers handy.

in short Rusty said the right thing is to use scripts/file2alias to generate module aliases out of input device id tables. While I do not object in principle, the reasons I did it the current way were

- it is consistent with how things are implemented currently and no one so far told me it is going to change

- I think it is more flexible. E.g. it provides for extra filtering (blacklisting) if needed. Doing this requires most of the current code (in some form) even in presence of aliases generated by file2alias

- given size of input id tables it will generate aliases of size more than 1k characters. Not that I really care but it is hardly readable.

- file2alias works only at kernel compile time. Users are free to install extra (binary) modules at any time and expect them to still be recognized.

I really think that keeping module-init-tools in sync with kernel is not much more difficult than keeping file2alias in sync with kernel. Whoever neglects update the former may just as well neglect to update the latter. And so far this was the main argument of Rusty IIRC.

cheers
and sorry for delay too

-andrey

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#5 lore raw
In reply to Andrey Borzenkov

In message <[email protected]> you write:

Quoted 7 lines
Quoted 2 lines

Thanks, I've applied this patch. Did your module-init-tools patch make it into that package too?

No, Rusty was against it. You should have received those mails as well (you were on Cc at least), subject was

"module-init-tools - input devices id support"

Let's go through this again.

1) I don't understand what you want. eg. for USB devices, they're used to match the USB device to the USB driver for autoloading.

You seemed surprised when I suggested you could autoload the input
drivers: but what else would you want this information for?

2) While a naive approach to aliases would make aliases for input drivers about 1000 chars long, that's just a good reason not to use a naive approach. I already suggested one approach based on the looking at the current drivers in the tree.

3) Since we're talking about 5 drivers in all, you could simply hardcode them if this is all too much trouble for you.

4) You *have* been informed that this is changing, months ago. As soon as Greg tells me that hotplug scripts no longer need those tables, they will be removed in favour of the aliases which exist.

5) If you want some tables for other reasons, there's no reason for you not to generate them yourself. Experience has shown that this method is fragile, but that's your choice.

6) You're confused about external modules: the module supplier runs file2alias as part of the build process, the user runs depmod as normal, so no problems.

Quoted 2 lines

I really think that keeping module-init-tools in sync with kernel is not much more difficult than keeping file2alias in sync with kernel.

But they are *distributed separately*, so for the end user, it's much harder to keep them in sync. That's been one of the main aims of the new module code: kernel independence.

Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel