Re: [PATCH] vt: Drop K_OFF for VC_MUTE

2012-12-12 Thread Arthur Taylor
>> Drop the K_OFF handling and replace it with a new "mute" ioctl pair. >> Anybody using K_OFF would already need to be prepared to handle it >> throwing -EINVAL for old kernel compatibility, so userspace will degrade >> gracefully. > > Interesting theory. It may degrade but it'll degrade to a stat

Re: [PATCH] vt: Drop K_OFF for VC_MUTE

2012-11-20 Thread Alan Cox
> Drop the K_OFF handling and replace it with a new "mute" ioctl pair. > Anybody using K_OFF would already need to be prepared to handle it > throwing -EINVAL for old kernel compatibility, so userspace will degrade > gracefully. Interesting theory. It may degrade but it'll degrade to a state worse

Re: [PATCH] vt: Drop K_OFF for VC_MUTE

2012-11-20 Thread Josh Boyer
On Fri, Nov 16, 2012 at 1:32 PM, Adam Jackson wrote: > The "don't enqueue stuff" semantics of K_OFF shouldn't be a function of > the keyboard map state; we should be able to switch among cooked/raw/ > unicode without changing whether events are delivered. Otherwise - if > changing to K_UNICODE un

[PATCH] vt: Drop K_OFF for VC_MUTE

2012-11-16 Thread Adam Jackson
The "don't enqueue stuff" semantics of K_OFF shouldn't be a function of the keyboard map state; we should be able to switch among cooked/raw/ unicode without changing whether events are delivered. Otherwise - if changing to K_UNICODE undoes K_OFF - then suddenly Alt-F2 under Gnome will switch VT i