Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello, Also, could serdev also provide an send_xchar function similar to the send_xchar tty driver function? We need this to send high-priority characters. Samuel

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Rob Herring, on mer. 15 mars 2017 09:45:59 -0500, wrote: > On Mon, Mar 13, 2017 at 8:18 PM, Samuel Thibault > <samuel.thiba...@ens-lyon.org> wrote: > > Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > >> Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote:

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Rob Herring, on mer. 15 mars 2017 09:45:59 -0500, wrote: > On Mon, Mar 13, 2017 at 8:18 PM, Samuel Thibault > wrote: > > Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > >> Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > >> > On Mon,

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Dave Mielke, on lun. 13 mars 2017 22:20:01 -0400, wrote: > It's possible that this device is using high speed because it offers a > feature > to transfer its internal clipboard to the host, and it allows that clipboard > to > contain lots of data. Interestingly, though, hidden within a usage

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Dave Mielke, on lun. 13 mars 2017 22:20:01 -0400, wrote: > It's possible that this device is using high speed because it offers a > feature > to transfer its internal clipboard to the host, and it allows that clipboard > to > contain lots of data. Interestingly, though, hidden within a usage

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > > This patchset introduces a TTY-based way for the synths to communicate

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on mar. 14 mars 2017 01:47:01 +0100, wrote: > Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > > This patchset introduces a TTY-based way for the synths to communicate

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello, Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > This patchset introduces a TTY-based way for the synths to communicate > > with devices as an alternate for direct serial comms used by the synths > > at the

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello, Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > This patchset introduces a TTY-based way for the synths to communicate > > with devices as an alternate for direct serial comms used by the synths > > at the

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello Okash, I'd say for a start already, rebase and submit patches 2-5, since they are refactoring that makes sense anyway. And we can discuss about serdev while that gets integrated, and thus serdev-equivalents of patches 1 and 6 will then be immediatetly applicable. Samuel

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello Okash, I'd say for a start already, rebase and submit patches 2-5, since they are refactoring that makes sense anyway. And we can discuss about serdev while that gets integrated, and thus serdev-equivalents of patches 1 and 6 will then be immediatetly applicable. Samuel

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on lun. 13 mars 2017 23:26:08 +0100, wrote: > > That should make this a lot easier than your patchset from what I can > > see. > > Will serdev support modem line control? We need this for some devices. "serdev: add serdev_device_set_rts" seems to be saying yes :) Samuel

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Samuel Thibault, on lun. 13 mars 2017 23:26:08 +0100, wrote: > > That should make this a lot easier than your patchset from what I can > > see. > > Will serdev support modem line control? We need this for some devices. "serdev: add serdev_device_set_rts" seems to be saying yes :) Samuel

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Greg KH, on mar. 14 mars 2017 07:43:03 +0800, wrote: > > Well, for a start that didn't exist when Okash worked on the TTY part :) > > Fair enough, but it has been discussed for many months now on the > linux-serial mailing list. I have not had time for years to actually work on this subject, so

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Greg KH, on mar. 14 mars 2017 07:43:03 +0800, wrote: > > Well, for a start that didn't exist when Okash worked on the TTY part :) > > Fair enough, but it has been discussed for many months now on the > linux-serial mailing list. I have not had time for years to actually work on this subject, so

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello, Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > This patchset introduces a TTY-based way for the synths to communicate > > with devices as an alternate for direct serial comms used by the synths > > at the

Re: [patch 0/7] staging: speakup: introduce tty-based comms

Hello, Greg KH, on mar. 14 mars 2017 06:14:04 +0800, wrote: > On Mon, Mar 13, 2017 at 10:05:51PM +, okash.khaw...@gmail.com wrote: > > This patchset introduces a TTY-based way for the synths to communicate > > with devices as an alternate for direct serial comms used by the synths > > at the

[PATCHv3] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Acked-by: Alan Stern <st...@rowland.harvard.edu> --- a/inclu

[PATCHv3] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault Acked-by: Alan Stern --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@ -50,4 +50,10

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote: > On Sun, 12 Mar 2017, Dave Mielke wrote: > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400] > > > > >A device's speed is only partially related to its USB version. A > > >USB-1.1 device can run at low speed or full speed. A

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Alan Stern, on dim. 12 mars 2017 21:40:33 -0400, wrote: > On Sun, 12 Mar 2017, Dave Mielke wrote: > > [quoted lines by Alan Stern on 2017/03/12 at 21:31 -0400] > > > > >A device's speed is only partially related to its USB version. A > > >USB-1.1 device can run at low speed or full speed. A

[PATCHv2] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@

[PATCHv2] usb-core: Add LINEAR_FRAME_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_LINEAR_FRAME_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@ -50,4 +50,10 @@ /* device can't

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Alan Stern, on dim. 12 mars 2017 17:18:51 -0400, wrote: > Interesting. This is a high-speed device that mistakenly uses the > low/full-speed encoding for an interrupt bInterval value? Yes... > That's pretty unusual. Most HID devices (which includes the Braille > devices I have heard of) run

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Alan Stern, on dim. 12 mars 2017 17:18:51 -0400, wrote: > Interesting. This is a high-speed device that mistakenly uses the > low/full-speed encoding for an interrupt bInterval value? Yes... > That's pretty unusual. Most HID devices (which includes the Braille > devices I have heard of) run

[PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_MS_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@ -50,4

[PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

adds a USB_QUIRK_MS_INTR_BINTERVAL quirk to mark devices which actually report milliseconds in bInterval, and marks Vario Ultra devices as needing it. Signed-off-by: Samuel Thibault --- a/include/linux/usb/quirks.h +++ b/include/linux/usb/quirks.h @@ -50,4 +50,10 @@ /* device can't handle Link

Re: [patch 0/3] speakup: support 16bit unicode screen reading

Greg KH, on jeu. 09 mars 2017 17:25:51 +0100, wrote: > This is the second version of this series, correct? Next time, please > put a "v2" in them so that I know which to apply. Ah, yes, sorry. The only difference was the Reviewed-by lines. Thanks! Samuel

Re: [patch 0/3] speakup: support 16bit unicode screen reading

Greg KH, on jeu. 09 mars 2017 17:25:51 +0100, wrote: > This is the second version of this series, correct? Next time, please > put a "v2" in them so that I know which to apply. Ah, yes, sorry. The only difference was the Reviewed-by lines. Thanks! Samuel

[patch 2/3] speakup: convert screen reading to 16bit characters

yet, for simplicity for now it will ignore 16bit characters. For simplicity again, speakup messages are left in latin1 for now. Some coding style is fixed along the way. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Reviewed-by: Okash Khawaja <okash.khaw...@gmail.com>

[patch 2/3] speakup: convert screen reading to 16bit characters

yet, for simplicity for now it will ignore 16bit characters. For simplicity again, speakup messages are left in latin1 for now. Some coding style is fixed along the way. Signed-off-by: Samuel Thibault Reviewed-by: Okash Khawaja Index: linux-4.10/drivers/staging/speakup/main.c

[patch 3/3] speakup: add unicode variant of /dev/softsynth

hardcode the UTF-8 encoding. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Reviewed-by: Chris Brannon <ch...@the-brannons.com> Index: linux-4.10/drivers/staging/speakup/speakup_soft.c === --- linux-4.10.

[patch 3/3] speakup: add unicode variant of /dev/softsynth

hardcode the UTF-8 encoding. Signed-off-by: Samuel Thibault Reviewed-by: Chris Brannon Index: linux-4.10/drivers/staging/speakup/speakup_soft.c === --- linux-4.10.orig/drivers/staging/speakup/speakup_soft.c +++ linux-4.10/drivers

[patch 1/3] speakup: extend synth buffer to 16bit unicode characters

to put 16bit characters and strings. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Reviewed-by: Chris Brannon <ch...@the-brannons.com> Index: linux-4.10/drivers/staging/speakup/spk_priv.h === --- linux-4.10.

[patch 1/3] speakup: extend synth buffer to 16bit unicode characters

to put 16bit characters and strings. Signed-off-by: Samuel Thibault Reviewed-by: Chris Brannon Index: linux-4.10/drivers/staging/speakup/spk_priv.h === --- linux-4.10.orig/drivers/staging/speakup/spk_priv.h +++ linux-4.10/drivers

[patch 0/3] speakup: support 16bit unicode screen reading

Hello, This patch series adds 16bit unicode support to speakup, through three patches: - extend synth buffer to 16bit unicode characters - convert screen reading to 16bit characters - add unicode variant of /dev/softsynth Samuel -- Samuel "...Unix, MS-DOS, and Windows NT (also known as the

[patch 0/3] speakup: support 16bit unicode screen reading

Hello, This patch series adds 16bit unicode support to speakup, through three patches: - extend synth buffer to 16bit unicode characters - convert screen reading to 16bit characters - add unicode variant of /dev/softsynth Samuel -- Samuel "...Unix, MS-DOS, and Windows NT (also known as the

Re: [PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Marcin Ciupak, on jeu. 02 mars 2017 15:28:23 +0100, wrote: > - int val; > + int ret; > > - val = simple_strtoul(skip_spaces(start), , 10); > + ret = kstrtou8(skip_spaces(start), 10, dest); This is not the same, you need to have start properly move, since it's used below: >

Re: [PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Marcin Ciupak, on jeu. 02 mars 2017 15:28:23 +0100, wrote: > - int val; > + int ret; > > - val = simple_strtoul(skip_spaces(start), , 10); > + ret = kstrtou8(skip_spaces(start), 10, dest); This is not the same, you need to have start properly move, since it's used below: >

[patch 3/3] speakup: add unicode variant of /dev/softsynth

hardcode the UTF-8 encoding. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Index: linux-4.10/drivers/staging/speakup/speakup_soft.c === --- linux-4.10.orig/drivers/staging/speakup/speakup_soft.c +++ linux-4.10/d

[patch 3/3] speakup: add unicode variant of /dev/softsynth

hardcode the UTF-8 encoding. Signed-off-by: Samuel Thibault Index: linux-4.10/drivers/staging/speakup/speakup_soft.c === --- linux-4.10.orig/drivers/staging/speakup/speakup_soft.c +++ linux-4.10/drivers/staging/speakup/speakup_soft.c

[patch 1/3] speakup: extend synth buffer to 16bit unicode characters

to put 16bit characters and strings. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Index: linux-4.10/drivers/staging/speakup/spk_priv.h === --- linux-4.10.orig/drivers/staging/speakup/spk_priv.h +++ linux-4.10/d

[patch 1/3] speakup: extend synth buffer to 16bit unicode characters

to put 16bit characters and strings. Signed-off-by: Samuel Thibault Index: linux-4.10/drivers/staging/speakup/spk_priv.h === --- linux-4.10.orig/drivers/staging/speakup/spk_priv.h +++ linux-4.10/drivers/staging/speakup/spk_priv.h

[patch 2/3] speakup: convert screen reading to 16bit characters

yet, for simplicity for now it will ignore 16bit characters. For simplicity again, speakup messages are left in latin1 for now. Some coding style is fixed along the way. Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Index: linux-4.10/drivers/staging/speakup/

[patch 0/3] speakup: support 16bit unicode screen reading

Hello, This patch series adds 16bit unicode support to speakup, through three patches: - extend synth buffer to 16bit unicode characters - convert screen reading to 16bit characters - add unicode variant of /dev/softsynth Samuel -- Samuel hm. I've lost a machine.. literally _lost_. it

[patch 2/3] speakup: convert screen reading to 16bit characters

yet, for simplicity for now it will ignore 16bit characters. For simplicity again, speakup messages are left in latin1 for now. Some coding style is fixed along the way. Signed-off-by: Samuel Thibault Index: linux-4.10/drivers/staging/speakup/main.c

[patch 0/3] speakup: support 16bit unicode screen reading

Hello, This patch series adds 16bit unicode support to speakup, through three patches: - extend synth buffer to 16bit unicode characters - convert screen reading to 16bit characters - add unicode variant of /dev/softsynth Samuel -- Samuel hm. I've lost a machine.. literally _lost_. it

Re: [PATCH SPEAKUP v2 3/3] use spkeaup_allocate as per required context

n. > > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > drivers/staging/speakup/main.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/stag

Re: [PATCH SPEAKUP v2 1/3] return same error value from spk_set_key_info

> > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > drivers/staging/speakup/main.c | 27 +++ > 1 file changed, 19 insertions(+), 8 deletions(-) > > diff --git a/

Re: [PATCH SPEAKUP v2 3/3] use spkeaup_allocate as per required context

n. > > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/main.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c > ind

Re: [PATCH SPEAKUP v2 1/3] return same error value from spk_set_key_info

> > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/main.c | 27 +++ > 1 file changed, 19 insertions(+), 8 deletions(-) > > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/ma

Re: [PATCH SPEAKUP v2 2/3] remove unecessary initial allocation of vc

> > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > drivers/staging/speakup/main.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/staging/speakup/main.c b/drivers

Re: [PATCH SPEAKUP v2 2/3] remove unecessary initial allocation of vc

> > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/main.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c > index a1d5b66..ca817ca 100644

Re: [PATCH-SPEAKUP 2/2] remove unecessary initial allocation of vc

gt; > Also change the prototype of speakup_allocate to take > extra argument of gfp_* flags. Thus not requiring > GFP_ATOMIC during initialization. > > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>

Re: [PATCH-SPEAKUP 2/2] remove unecessary initial allocation of vc

gt; > Also change the prototype of speakup_allocate to take > extra argument of gfp_* flags. Thus not requiring > GFP_ATOMIC during initialization. > > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/main.c | 19

Re: [PATCH-SPEAKUP 1/2] return same error value from spk_set_key_info

> > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > drivers/staging/speakup/main.c | 27 +++ > 1 file changed, 19 insertions(+), 8 deletions(-) > > diff --git a/

Re: [PATCH-SPEAKUP 1/2] return same error value from spk_set_key_info

> > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/main.c | 27 +++ > 1 file changed, 19 insertions(+), 8 deletions(-) > > diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/ma

Re: [PATCH] remove unnecessary initial allocation of vc

GFP_ATOMIC during initialization. > > Signed-off-by: Pranay Kr. Srivastava <pran...@gmail.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> Just add in the log that it's unnecessary because the for loop below does the initialization already. > ---

Re: [PATCH] remove unnecessary initial allocation of vc

GFP_ATOMIC during initialization. > > Signed-off-by: Pranay Kr. Srivastava Reviewed-by: Samuel Thibault Just add in the log that it's unnecessary because the for loop below does the initialization already. > --- > drivers/staging/speakup/main.c | 19 --- > 1

Re: [PATCH Speakup v2] return same error value from spk_set_key_info

Pranay Kr. Srivastava, on mar. 21 févr. 2017 19:14:38 +0530, wrote: > + if (key_data_len + SHIFT_TBL_SIZE + 4 >= sizeof(spk_key_buf)) { > + pr_debug("key_data_len = %d, SHIFT_TBL_SIZE + 4 = %d,\t" > + "sizeof(spk_key_buf) = %lu\n", key_data_len, > +

Re: [PATCH Speakup v2] return same error value from spk_set_key_info

Pranay Kr. Srivastava, on mar. 21 févr. 2017 19:14:38 +0530, wrote: > + if (key_data_len + SHIFT_TBL_SIZE + 4 >= sizeof(spk_key_buf)) { > + pr_debug("key_data_len = %d, SHIFT_TBL_SIZE + 4 = %d,\t" > + "sizeof(spk_key_buf) = %lu\n", key_data_len, > +

Re: [PATCH] return same error value from spk_set_key_info

Pranay Kr. Srivastava, on mar. 21 févr. 2017 17:24:42 +0530, wrote: > Retain the previous error values as debug messages > instead. Well, they are not really useful because they are actually undocumented. > + if (version != KEY_MAP_VER) { > + pr_debug("Version mismatch %d\n",

Re: [PATCH] return same error value from spk_set_key_info

Pranay Kr. Srivastava, on mar. 21 févr. 2017 17:24:42 +0530, wrote: > Retain the previous error values as debug messages > instead. Well, they are not really useful because they are actually undocumented. > + if (version != KEY_MAP_VER) { > + pr_debug("Version mismatch %d\n",

Re: [PATCH 0/4] TTY: fix Caps Lock LED

Benjamin Tissoires, on Fri 27 Jan 2017 19:34:36 +0100, wrote: > On Jan 27 2017 or thereabouts, Samuel Thibault wrote: > > > So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken > > > while > > > in a VT. > > > > Yes, and in Debian to

Re: [PATCH 0/4] TTY: fix Caps Lock LED

Benjamin Tissoires, on Fri 27 Jan 2017 19:34:36 +0100, wrote: > On Jan 27 2017 or thereabouts, Samuel Thibault wrote: > > > So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken > > > while > > > in a VT. > > > > Yes, and in Debian to

Re: [PATCH 4/4] Input: leds - force the LED status after .probe()

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:18 +0100, wrote: > Once the host has set the initial setting of the LEDs after a new > USB keyboard gets connected, they appear to have a SET_IDLE command > sent which turns of the LEDs. > This means that the initial step of setting the LEDs on a

Re: [PATCH 4/4] Input: leds - force the LED status after .probe()

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:18 +0100, wrote: > Once the host has set the initial setting of the LEDs after a new > USB keyboard gets connected, they appear to have a SET_IDLE command > sent which turns of the LEDs. > This means that the initial step of setting the LEDs on a

Re: [PATCH 3/4] tty/vt/keyboard: reset the LEDs state at each console change

Hello, Benjamin Tissoires, on Fri 27 Jan 2017 18:13:17 +0100, wrote: > When switching back from Gnome, the VT is not aware of the > current state of the LEDs. So if Gnome changes them, the > kernel still bellieves they are off, and it won't turn them > off when switching to a new TTY. I'm not

Re: [PATCH 3/4] tty/vt/keyboard: reset the LEDs state at each console change

Hello, Benjamin Tissoires, on Fri 27 Jan 2017 18:13:17 +0100, wrote: > When switching back from Gnome, the VT is not aware of the > current state of the LEDs. So if Gnome changes them, the > kernel still bellieves they are off, and it won't turn them > off when switching to a new TTY. I'm not

Re: [PATCH 2/4] tty/vt/keyboard: Fix Caps Lock LED on major distributions

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:16 +0100, wrote: > +static bool caps_as_controlllock; Really, we don't want these. Userspace could invent using another modifier, so it's really not the way forward. Please have a look at what I suggested. Samuel

Re: [PATCH 2/4] tty/vt/keyboard: Fix Caps Lock LED on major distributions

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:16 +0100, wrote: > +static bool caps_as_controlllock; Really, we don't want these. Userspace could invent using another modifier, so it's really not the way forward. Please have a look at what I suggested. Samuel

Re: [PATCH 0/4] TTY: fix Caps Lock LED

Hello, Benjamin Tissoires, on Fri 27 Jan 2017 18:13:14 +0100, wrote: > Well, it's quite an old issue, but it looks like no one cared much before :) I did, actually. > So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken while > in a VT. Yes, and in Debian too, see

Re: [PATCH 0/4] TTY: fix Caps Lock LED

Hello, Benjamin Tissoires, on Fri 27 Jan 2017 18:13:14 +0100, wrote: > Well, it's quite an old issue, but it looks like no one cared much before :) I did, actually. > So by default, on Fedora and RHEL at least*, the Caps Lock LED is broken while > in a VT. Yes, and in Debian too, see

Re: [PATCH 1/4] tty/vt/keyboard: use defined macros for masks

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:15 +0100, wrote: > Better using the defined macros to express the bit masks. > > Signed-off-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > dr

Re: [PATCH 1/4] tty/vt/keyboard: use defined macros for masks

Benjamin Tissoires, on Fri 27 Jan 2017 18:13:15 +0100, wrote: > Better using the defined macros to express the bit masks. > > Signed-off-by: Benjamin Tissoires Reviewed-by: Samuel Thibault > --- > drivers/tty/vt/keyboard.c | 6 +++--- > 1 file changed, 3 insertio

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Dietmar Eggemann, on Tue 20 Dec 2016 14:04:34 +0100, wrote: > On 12/20/2016 12:45 AM, Samuel Thibault wrote: > >Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > >>On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > >><samuel.thiba...@ens-lyon.org> wrote: >

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Dietmar Eggemann, on Tue 20 Dec 2016 14:04:34 +0100, wrote: > On 12/20/2016 12:45 AM, Samuel Thibault wrote: > >Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > >>On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > >> wrote: > >>>Paul Turner, o

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > <samuel.thiba...@ens-lyon.org> wrote: > > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> >> > - if (shares < MIN_SHARES) > &

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:32:15 -0800, wrote: > On Mon, Dec 19, 2016 at 3:29 PM, Samuel Thibault > wrote: > > Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> >> > - if (shares < MIN_SHARES) > >>

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> > - if (shares < MIN_SHARES) > >> > - shares = MIN_SHARES; > > ... > >> > return shares; > > > > This will only make sure that the returned shares is 2, not 2048. > > This is intentional. The MIN_SHARES you

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 15:26:19 -0800, wrote: > >> > - if (shares < MIN_SHARES) > >> > - shares = MIN_SHARES; > > ... > >> > return shares; > > > > This will only make sure that the returned shares is 2, not 2048. > > This is intentional. The MIN_SHARES you

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 14:44:38 -0800, wrote: > On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault > <samuel.thiba...@ens-lyon.org> wrote: > > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit > > kernels") > > > > exposed

Re: [PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

Paul Turner, on Mon 19 Dec 2016 14:44:38 -0800, wrote: > On Mon, Dec 19, 2016 at 2:40 PM, Samuel Thibault > wrote: > > 2159197d6677 ("sched/core: Enable increased load resolution on 64-bit > > kernels") > > > > exposed yet another miscalculation in calc

[PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

2159197d6677 ("sched/core: Enable increased load resolution on 64-bit kernels") exposed yet another miscalculation in calc_cfs_shares: MIN_SHARES is unscaled, and must thus be scaled before being manipulated against "shares" amounts. Signed-off-by: Samuel Thibault <samue

[PATCH] sched/fair: fix calc_cfs_shares fixed point arithmetics

2159197d6677 ("sched/core: Enable increased load resolution on 64-bit kernels") exposed yet another miscalculation in calc_cfs_shares: MIN_SHARES is unscaled, and must thus be scaled before being manipulated against "shares" amounts. Signed-off-by: Samuel Thibault Cc: Peter

Re: [PATCH] vt: fix Scroll Lock LED trigger name

Hello, Pavel Machek, on Mon 05 Dec 2016 14:47:43 +0100, wrote: > > There is a disagreement between drivers/tty/vt/keyboard.c and > > drivers/input/input-leds.c with regard to what is a Scroll Lock LED > > trigger name: input calls it "kbd-scrolllock", but vt calls it > > "kbd-scrollock" (two

Re: [PATCH] vt: fix Scroll Lock LED trigger name

Hello, Pavel Machek, on Mon 05 Dec 2016 14:47:43 +0100, wrote: > > There is a disagreement between drivers/tty/vt/keyboard.c and > > drivers/input/input-leds.c with regard to what is a Scroll Lock LED > > trigger name: input calls it "kbd-scrolllock", but vt calls it > > "kbd-scrollock" (two

Re: [PATCH] vt: fix Scroll Lock LED trigger name

Hello, Greg Kroah-Hartman, on Wed 16 Nov 2016 08:24:42 +0100, wrote: > > static struct kbd_led_trigger kbd_led_triggers[] = { > > - KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"), > > + KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"), > > KBD_LED_TRIGGER(VC_NUMLOCK, "kbd-numlock"), > >

Re: [PATCH] vt: fix Scroll Lock LED trigger name

Hello, Greg Kroah-Hartman, on Wed 16 Nov 2016 08:24:42 +0100, wrote: > > static struct kbd_led_trigger kbd_led_triggers[] = { > > - KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"), > > + KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"), > > KBD_LED_TRIGGER(VC_NUMLOCK, "kbd-numlock"), > >

Re: [PATCH] vt: fix Scroll Lock LED trigger name

s LED let's simply rename it to "kbd-scrolllock". > > Also, it looks like this was supposed to be changed before this code was > merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on > the input side. > > Signed-off-by: Maciej S. Szmigiero <m...@m

Re: [PATCH] vt: fix Scroll Lock LED trigger name

s LED let's simply rename it to "kbd-scrolllock". > > Also, it looks like this was supposed to be changed before this code was > merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on > the input side. > > Signed-off-by: Maciej S. Szmigiero Acked-by: Samue

Re: [PATCH] staging: speakup: Replaced obsolete simple_strtoul

Hello, Jitendra Khasdev, on Thu 06 Oct 2016 02:02:58 +0530, wrote: > From: Jitendra Kumar Khasdev > > This patch is for replacing obsolete simple_strtoul to kstrtoul which remove > warning produce by checkpatch. > + unsigned long val; > + > + if (kstrtoul(start,

Re: [PATCH] staging: speakup: Replaced obsolete simple_strtoul

Hello, Jitendra Khasdev, on Thu 06 Oct 2016 02:02:58 +0530, wrote: > From: Jitendra Kumar Khasdev > > This patch is for replacing obsolete simple_strtoul to kstrtoul which remove > warning produce by checkpatch. > + unsigned long val; > + > + if (kstrtoul(start, 10, )) > +

Re: [PATCH] speakup: Add spinlock in synth_direct_store

Andrianov <andria...@ispras.ru> Reviewed-by: Samuel Thibault <samuel.thiba...@ens-lyon.org> > --- > drivers/staging/speakup/kobjects.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/staging/speakup/kobjects.c > b/drivers/staging/speakup/kobjects.c

Re: [PATCH] speakup: Add spinlock in synth_direct_store

drianov Reviewed-by: Samuel Thibault > --- > drivers/staging/speakup/kobjects.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/staging/speakup/kobjects.c > b/drivers/staging/speakup/kobjects.c > index 528cbdc..7fedee3 100644 > --- a/drivers/staging/

Re: A potential race in drivers/staging/speakup/speakup.ko

Pavel Andrianov, on Mon 05 Sep 2016 13:33:33 +0300, wrote: > synth_direct_store may be called via device_attributes interface. Ah, right. > In which function the lock should be added? That'd be synth_direct_store then, around the while loop. Samuel

Re: A potential race in drivers/staging/speakup/speakup.ko

Pavel Andrianov, on Mon 05 Sep 2016 13:33:33 +0300, wrote: > synth_direct_store may be called via device_attributes interface. Ah, right. > In which function the lock should be added? That'd be synth_direct_store then, around the while loop. Samuel

Re: A potential race in drivers/staging/speakup/speakup.ko

Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: > 05.09.2016 12:43, Samuel Thibault пишет: > >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > >>There is a potential race in drivers/staging/speakup/speakup.ko. > >>All operations with global po

Re: A potential race in drivers/staging/speakup/speakup.ko

Pavel Andrianov, on Mon 05 Sep 2016 12:54:10 +0300, wrote: > 05.09.2016 12:43, Samuel Thibault пишет: > >Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > >>There is a potential race in drivers/staging/speakup/speakup.ko. > >>All operations with global po

Re: A potential race in drivers/staging/speakup/speakup.ko

Hello, Pavel Andrianov, on Mon 05 Sep 2016 11:51:50 +0300, wrote: > There is a potential race in drivers/staging/speakup/speakup.ko. > All operations with global pointers buff_in and buff_out are performed > without any locks. Thus, a simultaneous write (via synth_buffer_clear or >

<    1   2   3   4   5   6   7   8   >