Lines Matching +full:button +full:- +full:up

9 just one button and the button is accessible at i/o port BUTTON_PORT. When
32 	    if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
33 		    printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
34 		    return -EBUSY;
39 		    printk(KERN_ERR "button.c: Not enough memory\n");
40 		    error = -ENOMEM;
44 	    button_dev->evbit[0] = BIT_MASK(EV_KEY);
45 	    button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
49 		    printk(KERN_ERR "button.c: Failed to register device\n");
82 and sets up input bitfields. This way the device driver tells the other
83 parts of the input systems what it is - what events can be generated or
88 	set_bit(EV_KEY, button_dev->evbit);
89 	set_bit(BTN_0, button_dev->keybit);
107 which upon every interrupt from the button checks its state and reports it
122 This doesn't seem important in the one button case, but is quite important
126 dev->open() and dev->close()
138 	    if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
139 		    printk(KERN_ERR "button.c: Can't allocate irq %d\n", button_irq);
140 		    return -EBUSY;
154 	    button_dev->open = button_open;
155 	    button_dev->close = button_close;
160 makes sure that dev->open() is called only when the first user connects
161 to the device and that dev->close() is called when the very last user
164 The open() callback should return a 0 in case of success or any non-zero value
171 maintaining relationships with input handlers - either already existing
185 releasing the runtime-PM reference it got in open() when the driver is using
186 runtime-PM.
195 inhibiting, sleeping and being a wakeup source is driver-specific.
197 Taking the analogy with the network devices - bringing a network interface down
198 doesn't mean that it should be impossible be wake the system up on LAN through
202 is not aware of input-specific inhibit (nor should it be).  Composite devices
203 containing several interfaces can be inhibited on a per-interface basis and e.g.
221 See uapi/linux/input-event-codes.h for the allowable values of code (from 0 to
222 KEY_MAX). Value is interpreted as a truth value, i.e. any non-zero value means
231 events are namely for joysticks and digitizers - devices that do work in an
239 function. Events are generated only for non-zero values.
243 struct for each absolute axis your device has. If our button device had also
258 max values), with noise in the data up to +- 4, and with a center flat
270 	BITS_TO_LONGS(x) - returns the length of a bitfield array in longs for
272 	BIT_WORD(x)	 - returns the index in the array in longs for bit x
273 	BIT_MASK(x)	 - returns the index in a long for bit x
278 The dev->name should be set before registering the input device by the input
279 device driver. It's a string like 'Generic button device' containing a
306 dev->getkeycode() and dev->setkeycode()
319 autorepeat for your device, just set EV_REP in dev->evbit. All will be
325 The other event types up to now are:
327 - EV_LED - used for the keyboard LEDs.
328 - EV_SND - used for keyboard beeps.
331 direction - from the system to the input device driver. If your input device
335     button_dev->event = button_event;
344 	    return -1;