On Fri, Jan 8, 2016 at 12:51 PM, Aniroop Mathur <aniroop.mathur@xxxxxxxxx> wrote: > On Sat, Jan 9, 2016 at 2:03 AM, One Thousand Gnomes > <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: >> On Sat, 9 Jan 2016 01:50:42 +0530 >> Aniroop Mathur <aniroop.mathur@xxxxxxxxx> wrote: >> >>> On Sat, Jan 9, 2016 at 1:43 AM, One Thousand Gnomes >>> <gnomes@xxxxxxxxxxxxxxxxxxx> wrote: >>> >> During system boot up, user space buf size is fixed, it cannot be >>> >> resized later and we cannot choose by hit&trial. >>> >> struct input_event* mBuffer = new input_event[mBuf]; >>> > >>> > Who says that won't change ? Imagine a future case where plugging in a >>> > device changes the buffer size ? >>> > >>> >>> Ofcourse buffer size can be changed but it will also change the value of bufsize >>> variable and accordingly user space client should also change its buf size. >> >> If its hot plugged why shouldn't that value change dynamically after >> you've asked ? >> > > Please put up your query clearly. what value ? what asked ? There is nothing that would stop us (kernel) to decide to resize the buffer after you issued your new EVIOCGBUFSIZE. For example one can decide to implement a feature that will double the size of evdev's client buffer if there happened too many overruns i a given time period. In any case the userpsace consumers already have to inspect input device in question (number of axes and what they are; number of keys/buttons, number of slots, etc) so that they can handle devices properly and it should have enough information to intelligently size of the receiving buffers. There is no need for a new kernel ioctl. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
