search for: input_register_device

...t4 resume=/dev/sda3 splash=silent showopts vga=0x314 module /boot/initrd-2.6.18.8-xen When I try to boot the system with "noacpi" option, it boots just fine. However, when I omit the noacpi option, the system prints the following warnings and then just hangs: EPI: [<c0252a31>] input_register_device+0xc7/0x260 SS:ESP 0069:ed301cdc udevd event[1685]:run-program: ''/sbin/modprobe'' abnormal exit Do you have any ideas how I could address this problem or point me in the right direction? Thank you. -- Vahid _______________________________________________ Xen-users mailing l...

...t; input_allocate_device, but worth checking, > > > and maybe adding a comment. > > > > Yes, it is OK to send events though yet unregistered input device, as > > long as it was allocated with input_allocate_device(). > > > > > > > > > + err = input_register_device(vi->idev); > > > > + if (err) > > > > + goto err_input_register; > > > > + > > > > + return 0; > > > > + > > > > +err_input_register: > > > > > > > + input_free_device(vi->idev); > > > &gt...

...t; input_allocate_device, but worth checking, > > > and maybe adding a comment. > > > > Yes, it is OK to send events though yet unregistered input device, as > > long as it was allocated with input_allocate_device(). > > > > > > > > > + err = input_register_device(vi->idev); > > > > + if (err) > > > > + goto err_input_register; > > > > + > > > > + return 0; > > > > + > > > > +err_input_register: > > > > > > > + input_free_device(vi->idev); > > > &gt...

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. I started with the Xen version at http://xenbits.xensource.com/linux-2.6.18-xen.hg?rev/ca05cf1a9bdc Differences to that Xen version, for those who care: * Rewritten on top of fb deferred

...+ vi->idev->sndbit, SND_CNT); > + > + if (test_bit(EV_ABS, vi->idev->evbit)) { > + for (abs = 0; abs < ABS_CNT; abs++) { > + if (!test_bit(abs, vi->idev->absbit)) > + continue; > + virtinput_cfg_abs(vi, abs); > + } > + } > + > + err = input_register_device(vi->idev); Once you do this, virtinput_status can get called, and that will kick, correct? If so, you must call device_ready before this. > + if (err) > + goto out4; > + > + return 0; > + > +out4: > + input_free_device(vi->idev); > +out3: > + vdev->config->...

...+ vi->idev->sndbit, SND_CNT); > + > + if (test_bit(EV_ABS, vi->idev->evbit)) { > + for (abs = 0; abs < ABS_CNT; abs++) { > + if (!test_bit(abs, vi->idev->absbit)) > + continue; > + virtinput_cfg_abs(vi, abs); > + } > + } > + > + err = input_register_device(vi->idev); Once you do this, virtinput_status can get called, and that will kick, correct? If so, you must call device_ready before this. > + if (err) > + goto out4; > + > + return 0; > + > +out4: > + input_free_device(vi->idev); > +out3: > + vdev->config->...

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. Differences since last post: * Required patch fixing 32-on-64 xen-blkfront included. * Cleanup when xenkbd_probe() fails fixed. * Don't store event channel in device info. I started

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. Differences since last post: * Required patch fixing 32-on-64 xen-blkfront included. * Cleanup when xenkbd_probe() fails fixed. * Don't store event channel in device info. I started

This is a pair of Xen para-virtual frontend device drivers: drivers/video/xen-fbfront.c provides a framebuffer, and drivers/input/xen-kbdfront provides keyboard and mouse. The backends run in dom0 user space. Differences since last post: * Required patch fixing 32-on-64 xen-blkfront included. * Cleanup when xenkbd_probe() fails fixed. * Don't store event channel in device info. I started

...L; > > + vi->idev->id.vendor = 0x0001; > > + vi->idev->id.product = 0x0001; > > + vi->idev->id.version = 0x0100; > > Add comments explaining why these #s make sense? See other subthread, will be changed to be host-provided (like name). > > + err = input_register_device(vi->idev); > > Once you do this, virtinput_status can get called, > and that will kick, correct? Correct. > If so, you must call device_ready before this. Ok. > > + if (err) > > + goto out4; > > + > > + return 0; > > + > > +out4: > > +...

...L; > > + vi->idev->id.vendor = 0x0001; > > + vi->idev->id.product = 0x0001; > > + vi->idev->id.version = 0x0100; > > Add comments explaining why these #s make sense? See other subthread, will be changed to be host-provided (like name). > > + err = input_register_device(vi->idev); > > Once you do this, virtinput_status can get called, > and that will kick, correct? Correct. > If so, you must call device_ready before this. Ok. > > + if (err) > > + goto out4; > > + > > + return 0; > > + > > +out4: > > +...

...nput_cfg_bits(vi, VIRTIO_INPUT_CFG_EV_BITS, EV_SND, + vi->idev->sndbit, SND_CNT); + + if (test_bit(EV_ABS, vi->idev->evbit)) { + for (abs = 0; abs < ABS_CNT; abs++) { + if (!test_bit(abs, vi->idev->absbit)) + continue; + virtinput_cfg_abs(vi, abs); + } + } + err = input_register_device(vi->idev); + if (err) + goto err_input_register; + + virtio_device_ready(vdev); + vi->ready = true; + virtinput_fill_evt(vi); + return 0; + +err_input_register: + input_free_device(vi->idev); +err_input_alloc: + vdev->config->del_vqs(vdev); +err_init_vq: + kfree(vi); + return err; +...

...nput_cfg_bits(vi, VIRTIO_INPUT_CFG_EV_BITS, EV_SND, + vi->idev->sndbit, SND_CNT); + + if (test_bit(EV_ABS, vi->idev->evbit)) { + for (abs = 0; abs < ABS_CNT; abs++) { + if (!test_bit(abs, vi->idev->absbit)) + continue; + virtinput_cfg_abs(vi, abs); + } + } + err = input_register_device(vi->idev); + if (err) + goto err_input_register; + + virtio_device_ready(vdev); + vi->ready = true; + virtinput_fill_evt(vi); + return 0; + +err_input_register: + input_free_device(vi->idev); +err_input_alloc: + vdev->config->del_vqs(vdev); +err_init_vq: + kfree(vi); + return err; +...

...= 0x0001; > > > + vi->idev->id.product = 0x0001; > > > + vi->idev->id.version = 0x0100; > > > > Add comments explaining why these #s make sense? > > See other subthread, will be changed to be host-provided (like name). > > > > + err = input_register_device(vi->idev); > > > > Once you do this, virtinput_status can get called, > > and that will kick, correct? > > Correct. > > > If so, you must call device_ready before this. > > Ok. > > > > + if (err) > > > + goto out4; > > >...

...= 0x0001; > > > + vi->idev->id.product = 0x0001; > > > + vi->idev->id.version = 0x0100; > > > > Add comments explaining why these #s make sense? > > See other subthread, will be changed to be host-provided (like name). > > > > + err = input_register_device(vi->idev); > > > > Once you do this, virtinput_status can get called, > > and that will kick, correct? > > Correct. > > > If so, you must call device_ready before this. > > Ok. > > > > + if (err) > > > + goto out4; > > >...

Hi, This patch adds a virtio driver for input devices. Specification: https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007 Qemu patches; https://lists.gnu.org/archive/html/qemu-devel/2015-03/threads.html#03973 Gerd Hoffmann (1): Add virtio-input driver. drivers/virtio/Kconfig | 10 ++

Hi, This patch adds a virtio driver for input devices. Specification: https://www.kraxel.org/cgit/virtio-spec/log/?h=virtio-input https://www.kraxel.org/virtio/virtio-v1.0-csprd03-virtio-input.html#x1-2640007 Qemu patches; https://lists.gnu.org/archive/html/qemu-devel/2015-03/threads.html#03973 Gerd Hoffmann (1): Add virtio-input driver. drivers/virtio/Kconfig | 10 ++

...BS, vi->idev->evbit)) { 287 for (abs = 0; abs < ABS_CNT; abs++) { 288 if (!test_bit(abs, vi->idev->absbit)) 289 continue; 290 virtinput_cfg_abs(vi, abs); 291 } 292 } 293 294 virtio_device_ready(vdev); 295 vi->ready = true; 296 err = input_register_device(vi->idev); 297 if (err) 298 goto err_input_register; 299 300 virtinput_fill_evt(vi); 301 return 0; 302 303 err_input_register: 304 spin_lock_irqsave(&vi->lock, flags); 305 vi->ready = false; 306 spin_unlock_irqrestore(&vi->lock, flags);...