On Mon, Mar 23, 2015 at 04:05:29PM +0100, Gerd Hoffmann wrote:
> On Mo, 2015-03-23 at 15:54 +0100, Michael S. Tsirkin wrote:
> > On Mon, Mar 23, 2015 at 03:27:35PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > > > You are doing leXXX everywhere, that's VERSION_1 dependency.
> > > > > > >
On Mon, 23 Mar 2015 16:05:29 +0100
Gerd Hoffmann wrote:
> On Mo, 2015-03-23 at 15:54 +0100, Michael S. Tsirkin wrote:
> > On Mon, Mar 23, 2015 at 03:27:35PM +0100, Gerd Hoffmann wrote:
> > > Hi,
> > >
> > > > > > > You are doing leXXX everywhere, that's VERSION_1 dependency.
> > > > > > > virt
On Mo, 2015-03-23 at 15:54 +0100, Michael S. Tsirkin wrote:
> On Mon, Mar 23, 2015 at 03:27:35PM +0100, Gerd Hoffmann wrote:
> > Hi,
> >
> > > > > > You are doing leXXX everywhere, that's VERSION_1 dependency.
> > > > > > virtio_cread will do byteswaps differently without VERSION_1.
> > > > > >
On Mon, Mar 23, 2015 at 03:27:35PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > > > You are doing leXXX everywhere, that's VERSION_1 dependency.
> > > > > virtio_cread will do byteswaps differently without VERSION_1.
> > > > > Just don't go there.
>
> > So to clarify, you dislike using __virtio32
Hi,
> > > > You are doing leXXX everywhere, that's VERSION_1 dependency.
> > > > virtio_cread will do byteswaps differently without VERSION_1.
> > > > Just don't go there.
> So to clarify, you dislike using __virtio32 in virtio input header?
Well, as I understand things __virtio32 implies byte
On Mon, Mar 23, 2015 at 02:44:52PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > At least, this needs a comment explaining what the function does,
> > > and maybe wrap it in a helper like virtio_input_bitmap_copy or
> > > virtio_bitmap_or.
> >
> > Can do that, sure.
>
> Well, the function where th
Hi,
> > At least, this needs a comment explaining what the function does,
> > and maybe wrap it in a helper like virtio_input_bitmap_copy or
> > virtio_bitmap_or.
>
> Can do that, sure.
Well, the function where this is in already cares about the bitmap copy
only. Can add a comment though.
>
Hi,
> > > > + if (cfg & (1 << (bit % 8)))
> > > > + set_bit(bit, bits);
> > >
> > > what if not set? does something clear the mask?
> >
> > kzalloc?
>
> So you are really just reading in array of bytes?
> All this set bit trickery is just to convert things
On Fri, Mar 20, 2015 at 11:28:47AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > +static int virtinput_send_status(struct virtio_input *vi,
> > > + u16 type, u16 code, s32 value)
> > > +{
> > > + struct virtio_input_event *stsbuf;
> > > + struct scatterlist sg[1];
> > > +
>
Hi
On Fri, Mar 20, 2015 at 11:36 AM, Gerd Hoffmann wrote:
>> I'd like to see all four forwarded from the host. I'd be fine with
>> "bus" being set to VIRTUAL, but I'm not sure why that would be a good
>> thing to do?
>
> I think for the emulated devices it's fine to use VIRTUAL.
Yes, on the host
Hi,
> > There will also be pass-through support, i.e. qemu
> > opening /dev/input/event and forwarding everything to the guest.
> > How should that be handled best? Copy all four from the host? Even
> > though the bustype is BUS_USB? Not sure this actually improves things
> > because the gues
Hi,
> > +static int virtinput_send_status(struct virtio_input *vi,
> > +u16 type, u16 code, s32 value)
> > +{
> > + struct virtio_input_event *stsbuf;
> > + struct scatterlist sg[1];
> > +
> > + stsbuf = kzalloc(sizeof(*stsbuf), GFP_ATOMIC);
> > + if (!stsbuf)
Hi
On Fri, Mar 20, 2015 at 10:48 AM, Gerd Hoffmann wrote:
>
> Hi,
>
>> > +static int virtinput_send_status(struct virtio_input *vi,
>> > +u16 type, u16 code, s32 value)
>> > +{
>> > + struct virtio_input_event *stsbuf;
>> > + struct scatterlist sg[1];
Hi,
> > > +static ssize_t serial_show(struct device *dev,
> > > + struct device_attribute *attr, char *buf)
> > > +{
> > > + struct input_dev *idev = to_input_dev(dev);
> > > + struct virtio_input *vi = input_get_drvdata(idev);
> > > + return sprintf(bu
Hi,
> > +static int virtinput_send_status(struct virtio_input *vi,
> > +u16 type, u16 code, s32 value)
> > +{
> > + struct virtio_input_event *stsbuf;
> > + struct scatterlist sg[1];
> > +
> > + stsbuf = kzalloc(sizeof(*stsbuf), GFP_ATOMIC);
> >
Hey
On Thu, Mar 19, 2015 at 5:27 PM, Dmitry Torokhov
wrote:
> On Thu, Mar 19, 2015 at 01:29:49PM +0100, David Herrmann wrote:
[...]
>> > +static int virtinput_probe(struct virtio_device *vdev)
>> > +{
>> > + struct virtio_input *vi;
>> > + size_t size;
>> > + int abs, err;
>> >
On Thu, Mar 19, 2015 at 01:29:49PM +0100, David Herrmann wrote:
> Hi
>
> (CC: Dmitry)
>
> On Thu, Mar 19, 2015 at 10:13 AM, Gerd Hoffmann wrote:
> > virtio-input is basically evdev-events-over-virtio, so this driver isn't
> > much more than reading configuration from config space and forwarding
Hi
(CC: Dmitry)
On Thu, Mar 19, 2015 at 10:13 AM, Gerd Hoffmann wrote:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann
On Thu, Mar 19, 2015 at 10:13:11AM +0100, Gerd Hoffmann wrote:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann
What worr
virtio-input is basically evdev-events-over-virtio, so this driver isn't
much more than reading configuration from config space and forwarding
incoming events to the linux input layer.
Signed-off-by: Gerd Hoffmann
---
drivers/virtio/Kconfig| 10 ++
drivers/virtio/Makefile
20 matches
Mail list logo
