The alienware graphics amplifier is a device that provides external
access to a full PCIe slot, USB hub, and additional control zone.
This patch enables support for reading status whether the cable is
plugged in as well as for setting the colors in the new zone.
Signed-off-by: Mario Limonciello
This allows configuration the system for wakeup with a controller.
The feature requires hardware architectural modifications and can
not be supported on on existing systems.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 100 +++
1
The X51-R3 is in the X51 family. It includes 3 internal
lighting zones as well as is the first AW desktop that
includes support for a graphics amplifier.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 24 +++-
1 file changed, 19 insertions(+), 5
This brings them more in line with the usage of whitespace
in other platforms.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform
Both of these systems support:
* 2 lighting control zones
* HDMI mux control
* deep sleep control (to enable wakup from controller)
The ASM201 also supports the external graphics amplifier.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 32
characters in deep sleep control patch
Other patches may have some areas that avoid going over 80 characters
still, but this matches the style of the existing driver. If you would
like these to go over 80 characters as well, please comment which areas
this is OK.
Mario Limonciello (5
The X51-R3 is in the X51 family. It includes 3 internal
lighting zones as well as is the first AW desktop that
includes support for a graphics amplifier.
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 24 +++-
This allows configuration the system for wakeup with a controller.
The feature requires hardware architectural modifications and can
not be supported on on existing systems.
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c
The alienware graphics amplifier is a device that provides external
access to a full PCIe slot, USB hub, and additional control zone.
This patch enables support for reading status whether the cable is
plugged in as well as for setting the colors in the new zone.
Signed-off-by: Mario Limonciello
This brings them more in line with the usage of whitespace
in other platforms.
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/platfo
Both of these systems support:
* 2 lighting control zones
* HDMI mux control
* deep sleep control (to enable wakup from controller)
The ASM201 also supports the external graphics amplifier.
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware
characters in deep sleep control patch
Other patches may have some areas that avoid going over 80 characters
still, but this matches the style of the existing driver. If you would
like these to go over 80 characters as well, please comment which areas
this is OK.
Mario Limonciello (5
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index e66c34d..eccd547 100644
--- a/drivers/platform/x86
This allows configuration the system for wakeup with a controller.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 103 ++-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 44
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index 1e1e594..dcd4f81 100644
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 114 ---
1 file changed, 93 insertions(+), 21 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index dcd4f81..e6f6322 100644
I've got some extensions for the alienware-wmi driver that have
been introduced for a few new platforms and can be controlled via the WMI
interface.
Mario Limonciello (4):
Add support for new platform, X51-R3
Add support for alienware graphics amplifier
Add support for deep sleep control
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
index e66c34d..eccd547
I've got some extensions for the alienware-wmi driver that have
been introduced for a few new platforms and can be controlled via the WMI
interface.
Mario Limonciello (4):
Add support for new platform, X51-R3
Add support for alienware graphics amplifier
Add support for deep sleep control
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 114 ---
1 file changed, 93 insertions(+), 21 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
This allows configuration the system for wakeup with a controller.
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 103 ++-
1 file changed, 102 insertions(+), 1 deletion(-)
diff --git a/drivers/platfo
Signed-off-by: Mario Limonciello <mario_limoncie...@dell.com>
---
drivers/platform/x86/alienware-wmi.c | 44
1 file changed, 29 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
d=5cab0098171712a9fd51399b06181c8dfdebe9c9
>
> ===
> commit 5cab0098171712a9fd51399b06181c8dfdebe9c9
> Author: Mario Limonciello
> Date: Wed Jun 10 19:40:47 2009 +
>
> dell-wmi: add additional keyboard events
>
> Upcoming Dell hardwar
===
commit 5cab0098171712a9fd51399b06181c8dfdebe9c9
Author: Mario Limonciello mario_limoncie...@dell.com
Date: Wed Jun 10 19:40:47 2009 +
dell-wmi: add additional keyboard events
Upcoming Dell hardware will send more keyboard events via WMI. Add
support for them
On 06/16/2015 12:25 AM, Mario Limonciello wrote:
On 06/03/2015 06:17 PM, Mario Limonciello wrote:
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when
On 06/16/2015 12:25 AM, Mario Limonciello wrote:
On 06/03/2015 06:17 PM, Mario Limonciello wrote:
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when
On 06/03/2015 06:17 PM, Mario Limonciello wrote:
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario
On 06/03/2015 06:17 PM, Mario Limonciello wrote:
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario Limonciello (3):
Add support for X51-R3
Add support
On 05/27/2015 02:36 PM, Limonciello, Mario wrote:
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario Limonciello (3):
Add support for X51-R3
Add support
On 05/28/2015 01:30 PM, Greg KH wrote:
On Wed, May 27, 2015 at 06:46:05PM -0500, Mario Limonciello wrote:
Then fix the GPU drivers.
Fix the GPU drivers.
Fix the GPU drivers.
Nope, fix the GPU drivers.
With a fix for the GPU drivers? Great, that's the only acceptable
solution.
thanks
On 05/28/2015 01:30 PM, Greg KH wrote:
On Wed, May 27, 2015 at 06:46:05PM -0500, Mario Limonciello wrote:
Then fix the GPU drivers.
Fix the GPU drivers.
Fix the GPU drivers.
Nope, fix the GPU drivers.
With a fix for the GPU drivers? Great, that's the only acceptable
solution.
thanks
or
userspace later on.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/alienware-wmi.c | 45
2 files changed, 46 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index
Upcoming platform X51-R3 will support 4 LED zones.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
Interface is only supported on the X51-R3 currently.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 110 +--
1 file changed, 91 insertions(+), 19 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario Limonciello (3):
Add support for X51-R3
Add support for Alienware graphics amplifier.
Capture cable
These events are outputted via the keyboard controller.
Right now the only actionable event is to restart the system
if the cable is removed, but the others are documented in
case they will be bubbled up to other parts of the kernel or
userspace later on.
Signed-off-by: Mario Limonciello
Upcoming platform X51-R3 will support 4 LED zones.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c | 24 +++-
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers
Interface is only supported on the X51-R3 currently.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c | 110 +--
1 file changed, 91 insertions(+), 19 deletions(-)
diff --git a/drivers/platform/x86/alienware
An upcoming Alienware platform, X51-R3 will support some new features in the
WMI BIOS control API as well as emit some scan codes when particular hardware
is used in conjunction.
Mario Limonciello (3):
Add support for X51-R3
Add support for Alienware graphics amplifier.
Capture cable
These events are outputted via the keyboard controller.
Right now the only actionable event is to restart the system
if the cable is removed, but the others are documented in
case they will be bubbled up to other parts of the kernel or
userspace later on.
Signed-off-by: Mario Limonciello
or
userspace later on.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/alienware-wmi.c | 45
2 files changed, 46 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers
On 04/10/2015 09:19 PM, Ben Gamari wrote:
Mario Limonciello writes:
snip
snip
Is this to say that the issue will be fixed with a BIOS update?
Cheers,
- Ben
From what I have gathered this is expected behavior that won't change. The EC
will intentionally drop packets while processing
On 04/10/2015 09:19 PM, Ben Gamari wrote:
Mario Limonciello mario_limoncie...@dell.com writes:
snip
snip
Is this to say that the issue will be fixed with a BIOS update?
Cheers,
- Ben
From what I have gathered this is expected behavior that won't change. The EC
will intentionally drop
On 04/10/2015 06:14 PM, Pali Rohár wrote:
On Saturday 11 April 2015 01:07:03 Mario Limonciello wrote:
I could see problem with using older kernels which are in more
stable or LTS distribution versions...
But it is nice that problems are fixes for future 4.0/4.1
versions.
And if you located
On 04/10/2015 05:39 PM, Pali Rohár wrote:
On Wednesday 25 February 2015 21:45:22 Pali Rohár wrote:
Hello Mario,
have you patched synaptics driver with some resetafter parameter?
And have some team in dell found reason for invalid packets?
Hi Pali,
The reason was found for the invalid packets
On 04/10/2015 05:39 PM, Pali Rohár wrote:
On Wednesday 25 February 2015 21:45:22 Pali Rohár wrote:
Hello Mario,
have you patched synaptics driver with some resetafter parameter?
And have some team in dell found reason for invalid packets?
Hi Pali,
The reason was found for the invalid packets
On 04/10/2015 06:14 PM, Pali Rohár wrote:
On Saturday 11 April 2015 01:07:03 Mario Limonciello wrote:
I could see problem with using older kernels which are in more
stable or LTS distribution versions...
But it is nice that problems are fixes for future 4.0/4.1
versions.
And if you located
On 03/24/2015 03:02 PM, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
While I agree in general, one comment.
We haven't decided about the patch yet. We may decide to bump up the _REV
to 6 when ACPI 6 is out instead.
I'd be happy with this too.
That said
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
Since we don't expose any way for the platform to detect that it's
running Linux, yes.
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted
On 03/24/2015 10:24 AM, Matt Fleming wrote:
On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
Running a recent kernel is the tradeoff to be paid for using brand new
hardware. I certainly don't expect to be able to install a 4-year old
version of Fedora on a laptop released this year
On 03/24/2015 04:17 AM, Liam Girdwood wrote:
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
There is some work in progress here to standardise the jack kcontrols
between HDA, ASoC and other ALSA drivers. I would expect this to be
upstream in the next week or two.
UCM configs
On 03/24/2015 04:17 AM, Liam Girdwood wrote:
On Tue, 2015-03-24 at 00:50 -0500, Mario Limonciello wrote:
There is some work in progress here to standardise the jack kcontrols
between HDA, ASoC and other ALSA drivers. I would expect this to be
upstream in the next week or two.
UCM configs
On 03/24/2015 01:01 PM, Matthew Garrett wrote:
On Tue, Mar 24, 2015 at 12:22:18PM -0500, Mario Limonciello wrote:
Since we don't expose any way for the platform to detect that it's
running Linux, yes.
Will it? You haven't shipped the firmware that changes this behaviour
yet.
This was posted
On 03/24/2015 03:02 PM, Rafael J. Wysocki wrote:
On Tuesday, March 24, 2015 03:24:12 PM Matt Fleming wrote:
While I agree in general, one comment.
We haven't decided about the patch yet. We may decide to bump up the _REV
to 6 when ACPI 6 is out instead.
I'd be happy with this too.
That said
On 03/24/2015 10:24 AM, Matt Fleming wrote:
On Tue, 24 Mar, at 12:50:47AM, Mario Limonciello wrote:
Running a recent kernel is the tradeoff to be paid for using brand new
hardware. I certainly don't expect to be able to install a 4-year old
version of Fedora on a laptop released this year
On 03/23/2015 07:04 AM, Matt Fleming wrote:
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
Sadly no, Dell are not doing something useful. Their use of _REV is
entirely misguided for the same reasons using _OSI(Linux) is discouraged
in drivers/acpi/osl.c; namely that working around kernel
On 03/23/2015 07:04 AM, Matt Fleming wrote:
On Mon, 16 Mar, at 04:21:51PM, Jason Ekstrand wrote:
Sadly no, Dell are not doing something useful. Their use of _REV is
entirely misguided for the same reasons using _OSI(Linux) is discouraged
in drivers/acpi/osl.c; namely that working around kernel
On 03/16/2015 04:07 PM, Benjamin Tissoires wrote:
On Mon, Mar 16, 2015 at 4:57 PM, Jason Ekstrand wrote:
Yes, that's the gist of it.
Mario, you might not have seen the problem because you are not running
wayland and/or libinput. The xorg synaptics driver is much more
relaxed concerning what it
On 03/16/2015 03:42 PM, Jason Ekstrand wrote:
On Mon, Mar 16, 2015 at 11:50 AM, Mario Limonciello
wrote:
Thanks,
I'm now running a hacked up kernel that's Torvalds' tree from Saturday
morning (same as before) + a patch from Benjamin to fix the touchpad +
the DSDT hack given above
On 03/16/2015 12:10 PM, Jason Ekstrand wrote:
On Mon, Mar 16, 2015 at 7:29 AM, Mario Limonciello
wrote:
It's nothing about the wireless. I swapped it out for an intel card
on day 3 or so.
Yes, I am almost 100% sure that this affects suspend/resume. Prior to
the _REV hack, my laptop *never
On 03/14/2015 02:17 PM, Benjamin Tissoires wrote:
[top posting, sorry]
Jason made some interesting progress today:
with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card
is not switched in the I2S mode and works while the touchpad keeps
using I2C.
It looks like suspend/resume is
On 03/16/2015 04:07 PM, Benjamin Tissoires wrote:
On Mon, Mar 16, 2015 at 4:57 PM, Jason Ekstrand ja...@jlekstrand.net wrote:
Yes, that's the gist of it.
Mario, you might not have seen the problem because you are not running
wayland and/or libinput. The xorg synaptics driver is much more
On 03/14/2015 02:17 PM, Benjamin Tissoires wrote:
[top posting, sorry]
Jason made some interesting progress today:
with the patch in https://lkml.org/lkml/2015/3/12/149, the sound card
is not switched in the I2S mode and works while the touchpad keeps
using I2C.
It looks like suspend/resume is
On 03/16/2015 03:42 PM, Jason Ekstrand wrote:
On Mon, Mar 16, 2015 at 11:50 AM, Mario Limonciello
mario_limoncie...@dell.com wrote:
Thanks,
I'm now running a hacked up kernel that's Torvalds' tree from Saturday
morning (same as before) + a patch from Benjamin to fix the touchpad +
the DSDT hack
On 03/16/2015 12:10 PM, Jason Ekstrand wrote:
On Mon, Mar 16, 2015 at 7:29 AM, Mario Limonciello
mario_limoncie...@dell.com wrote:
It's nothing about the wireless. I swapped it out for an intel card
on day 3 or so.
Yes, I am almost 100% sure that this affects suspend/resume. Prior
On 02/20/2015 02:41 PM, Pali Rohár wrote:
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:
resetafter=0 means to never reset (even if driver receive e.g
thousand invalid packets). I think this is very dangerous if
there will be other bugs either in linux driver or some other HW
On 02/23/2015 06:51 PM, Dmitry Torokhov wrote:
On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote:
I am not sure what exactly the issue is... We do need to have the break
code to know when the key is released. We can't go and say that we will
release old key when we detect another key
On 02/23/2015 06:01 PM, Pali Rohár wrote:
On Tuesday 24 February 2015 00:31:52 Mario Limonciello wrote:
For older dell models (some old inspirions and maybe also
latitude) it was possible to use undocumented DELLDIAG interface
(which enter into SMM mode and call some functions) to enable
On 02/23/2015 06:01 PM, Pali Rohár wrote:
On Tuesday 24 February 2015 00:31:52 Mario Limonciello wrote:
For older dell models (some old inspirions and maybe also
latitude) it was possible to use undocumented DELLDIAG interface
(which enter into SMM mode and call some functions) to enable
On 02/23/2015 06:51 PM, Dmitry Torokhov wrote:
On Sun, Feb 22, 2015 at 05:55:05PM +0100, Pali Rohár wrote:
I am not sure what exactly the issue is... We do need to have the break
code to know when the key is released. We can't go and say that we will
release old key when we detect another key
On 02/20/2015 02:41 PM, Pali Rohár wrote:
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:
resetafter=0 means to never reset (even if driver receive e.g
thousand invalid packets). I think this is very dangerous if
there will be other bugs either in linux driver or some other HW
On 02/22/2015 10:55 AM, Pali Rohár wrote:
Thank you for information!
Sure, no problem.
Mario, do you know if it is possible to "switch" keyboard into
mode under which Fn key will send scancode (like Ctrl or Alt)
when presses, so it could be possible to use any Fn+key
combination for keyboard
On 02/22/2015 10:55 AM, Pali Rohár wrote:
Thank you for information!
Sure, no problem.
Mario, do you know if it is possible to switch keyboard into
mode under which Fn key will send scancode (like Ctrl or Alt)
when presses, so it could be possible to use any Fn+key
combination for keyboard
On 02/20/2015 03:46 PM, Pali Rohár wrote:
On Friday 20 February 2015 22:40:38 Mario Limonciello wrote:
Maybe stupid question, but cannot you call that code which put
sound card into HDA mode from kernel? It could fix problem when
either sound or touchpad is not working...
As I understand
On 02/20/2015 03:31 PM, Benjamin Tissoires wrote:
What is most likely happening is that the synaptics driver switches
the touchpad into the i2c/hid protocol. And yes Synaptics told us that
only a reset re-enables the touchpad in the PS/2 mode.
Kernels 3.11 and later know how to deal with this
On 02/20/2015 02:41 PM, Pali Rohár wrote:
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:
I have BIOS version A05 on my E6440 machine. That version does
not have problems with "repeating keys" and my workaround for
ALPS touchpad (which is in mainline tree and -stable
Hi Pali & Dmitry,
On 02/20/2015 01:24 PM, Pali Rohár wrote:
On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote:
Hi Mario,
On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello
wrote:
Can it be related to ther Dell models (Latitudes with ALPS
touchpad) also sending junk
On 02/20/2015 02:41 PM, Pali Rohár wrote:
On Friday 20 February 2015 20:56:23 Mario Limonciello wrote:
I have BIOS version A05 on my E6440 machine. That version does
not have problems with repeating keys and my workaround for
ALPS touchpad (which is in mainline tree and -stable trees now)
works
On 02/20/2015 03:46 PM, Pali Rohár wrote:
On Friday 20 February 2015 22:40:38 Mario Limonciello wrote:
Maybe stupid question, but cannot you call that code which put
sound card into HDA mode from kernel? It could fix problem when
either sound or touchpad is not working...
As I understand
On 02/20/2015 03:31 PM, Benjamin Tissoires wrote:
What is most likely happening is that the synaptics driver switches
the touchpad into the i2c/hid protocol. And yes Synaptics told us that
only a reset re-enables the touchpad in the PS/2 mode.
Kernels 3.11 and later know how to deal with this
Hi Pali Dmitry,
On 02/20/2015 01:24 PM, Pali Rohár wrote:
On Friday 20 February 2015 19:47:17 Dmitry Torokhov wrote:
Hi Mario,
On Thu, Feb 19, 2015 at 12:16:51PM -0600, Mario Limonciello
wrote:
Can it be related to ther Dell models (Latitudes with ALPS
touchpad) also sending junk data
Hi Dmitry,
On 02/19/2015 11:16 AM, Dmitry Torokhov wrote:
What kind of glitch is this? Is there a certain pattern to it? Even if we do
not reset the mouse the logs will be full of error messages.
Thanks.
From waveform capture data leaving the touchpad is valid, but when it is resent
Hi Dmitry,
On 02/19/2015 11:16 AM, Dmitry Torokhov wrote:
What kind of glitch is this? Is there a certain pattern to it? Even if we do
not reset the mouse the logs will be full of error messages.
Thanks.
From waveform capture data leaving the touchpad is valid, but when it is resent
When the touchpad for the Dell XPS 13 is running in PS/2 mode the
EC has a tendency to glitch causing the driver to receive bad data.
This doesn't affect the usage of the touchpad until enough bad data
is received that causes the driver to reset and "freeze".
Signed-off-by: Mario L
When the touchpad for the Dell XPS 13 is running in PS/2 mode the
EC has a tendency to glitch causing the driver to receive bad data.
This doesn't affect the usage of the touchpad until enough bad data
is received that causes the driver to reset and freeze.
Signed-off-by: Mario Limonciello
On 08/26/2014 12:20 PM, Tom Gundersen wrote:
On Tue, Aug 26, 2014 at 7:14 PM, Luis R. Rodriguez wrote:
The rework is now upstream, but not yet released [1].
The dell driver dose not use rely on udev in userspace, nor the
/lib/firmware path. It has its own userspace component, which just
On 08/26/2014 12:20 PM, Tom Gundersen wrote:
On Tue, Aug 26, 2014 at 7:14 PM, Luis R. Rodriguezmcg...@suse.com wrote:
The rework is now upstream, but not yet released [1].
The dell driver dose not use rely on udev in userspace, nor the
/lib/firmware path. It has its own userspace component,
Not all HW supporting WMAX method will support the HDMI mux feature.
Explicitly quirk the HW that does support it.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers
Not all HW supporting WMAX method will support the HDMI mux feature.
Explicitly quirk the HW that does support it.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c | 22 --
1 file changed, 20 insertions(+), 2 deletions
Since there are now multiple HDMI attributes associated with the WMAX method,
create a sysfs group for them instead.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 116 +-
1 file changed, 86 insertions(+), 30 deletions(-)
diff --git
This more closely reflects what the hardware can actually support.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers/platform/x86/alienware-wmi.c
This more closely reflects what the hardware can actually support.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/platform/x86/alienware-wmi.c
b/drivers
Since there are now multiple HDMI attributes associated with the WMAX method,
create a sysfs group for them instead.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c | 116 +-
1 file changed, 86 insertions
Intel build bot caught a few errors with alienware_wmi not testing for
bad results when allocated memory. Here's the fixes for them.
Mario Limonciello (1):
alienware-wmi: cover some scenarios where memory allocations would
fail
drivers/platform/x86/alienware-wmi.c | 12 ++--
1
Intel test builder caught a few instances that should test if kzalloc failed to
allocate memory as well as a scenario that platform_driver wasn't properly
initialized.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/alienware-wmi.c | 12 ++--
1 file changed, 10 insertions
Intel test builder caught a few instances that should test if kzalloc failed to
allocate memory as well as a scenario that platform_driver wasn't properly
initialized.
Signed-off-by: Mario Limonciello mario_limoncie...@dell.com
---
drivers/platform/x86/alienware-wmi.c | 12 ++--
1 file
Intel build bot caught a few errors with alienware_wmi not testing for
bad results when allocated memory. Here's the fixes for them.
Mario Limonciello (1):
alienware-wmi: cover some scenarios where memory allocations would
fail
drivers/platform/x86/alienware-wmi.c | 12 ++--
1
(in a
single line)
Mario Limonciello (1):
Add WMI driver for controlling AlienFX features on some Alienware
products
drivers/platform/x86/Kconfig | 12 +
drivers/platform/x86/Makefile| 2 +
drivers/platform/x86/alienware-wmi.c | 557 +++
3
(in a
single line)
Mario Limonciello (1):
Add WMI driver for controlling AlienFX features on some Alienware
products
drivers/platform/x86/Kconfig | 12 +
drivers/platform/x86/Makefile| 2 +
drivers/platform/x86/alienware-wmi.c | 557 +++
3
601 - 700 of 704 matches
Mail list logo
