_manager/powerd/system/internal_backlight.cc
[6] https://github.com/freedesktop/xorg-randrproto/blob/master/randrproto.txt
[7]
https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/drivers/modesetting/drmmode_display.c
[8]
https://gitlab.freedesktop.org/xorg/driver/xf86-video-inte
Hi David,
On 4/28/20 1:58 AM, David Santamaría Rogado wrote:
This is related to the issues at least on some devices for panel
orientation quirks where added.
Thank you for looking into this.
My tests have been done over a Lenovo ideapad D330.
This devices like the other ones that need panel
Hi all,
On 4/24/20 11:08 AM, Pekka Paalanen wrote:
On Fri, 24 Apr 2020 10:24:31 +0200
Hans de Goede wrote:
Agree on the hw-state prop reflecting the actual hardware state at
all times, that one is easy.
However, when userspace sets "privacy-screen-sw-state", the driver
should
Hi all,
Pekka, Rajat,
Thank you for your input in this.
On 4/24/20 9:40 AM, Pekka Paalanen wrote:
On Thu, 23 Apr 2020 11:21:47 -0700
Rajat Jain wrote:
On Tue, Apr 21, 2020 at 7:46 AM Pekka Paalanen wrote:
On Tue, 21 Apr 2020 14:37:41 +0200
Hans de Goede wrote:
TL;DR: Yes there will
Hi,
On 4/17/20 1:55 PM, Jani Nikula wrote:
On Fri, 17 Apr 2020, Pekka Paalanen wrote:
On Wed, 15 Apr 2020 17:40:46 +0200
Hans de Goede wrote:
Hi,
On 4/15/20 5:28 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Hans de Goede wrote:
ii. Currently the "privacy-screen" propert
Hi,
On 4/15/20 7:44 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 05:03:55PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Allows us to drop the cleanup code on the floor.
Sam noticed in his review:
With this change we avoid calling pci_disable_device()
twise
Hi,
On 4/15/20 11:10 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Rajat Jain wrote:
Hello,
On Wed, Apr 15, 2020 at 8:40 AM Hans de Goede wrote:
Hi,
On 4/15/20 5:28 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Hans de Goede wrote:
ii. Currently the "privacy-screen" propert
Hi,
On 4/15/20 8:29 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 8:19 PM Hans de Goede wrote:
Hi,
On 4/15/20 7:54 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 03:02:53PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 2:01 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 01:39:23PM
Hi,
On 4/15/20 7:54 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 03:02:53PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 2:01 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 01:39:23PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 12:22 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 12
Hi Mark,
On 4/15/20 7:14 PM, Mark Pearson wrote:
Hi,
-Original Message-
From: Hans de Goede
Sent: Wednesday, April 15, 2020 11:41 AM
On 4/15/20 5:28 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Hans de Goede wrote:
Moreover, do we actually need two properties, one which could
Hi,
On 4/15/20 5:28 PM, Jani Nikula wrote:
On Wed, 15 Apr 2020, Hans de Goede wrote:
ii. Currently the "privacy-screen" property added by Rajat's
patch-set is an enum with 2 possible values:
"Enabled"
"Disabled"
We could add a third value "Not Availab
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Upcasting using a container_of macro is more typesafe, faster and
easier for the compiler to optimize.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Already using devm_drm_dev_init, so very simple replacment.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u320.c | 13
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Aside from deleting all the cleanup code we're now also setting a name
for the pool
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vbox
eview remarks
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 6 ++
drivers/gpu/drm/vboxvideo/vbox_main.c | 7 +--
2 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
b/dr
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Doesn't apply to upstream kernels since a rather long time.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/vbox_ttm.c
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
Straightforward conversion.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/vboxvideo/vbox_drv.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions
Hi,
On 4/15/20 9:39 AM, Daniel Vetter wrote:
We use the baseclass pattern here, so lets to the proper (and more
typesafe) upcasting.
Acked-by: Sam Ravnborg
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
LGTM:
Reviewed-by: Hans de Goede
Regards,
Hans
Hi,
On 4/15/20 2:01 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 01:39:23PM +0200, Hans de Goede wrote:
Hi,
On 4/15/20 12:22 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 12:11 PM Hans de Goede wrote:
Hi,
On 4/15/20 11:52 AM, Daniel Vetter wrote:
iv. What every SoC subsystem
Hi,
On 4/15/20 1:39 PM, Hans de Goede wrote:
/* Add comment explaining why we need this messy stuff here */
const char * const shadow_providers[] = {
#ifdef CONFIG_THINKPAD_ACPI_MODULE
"thinkpad_acpi",
#endif
#ifdef CONFIG_OTHER_MODULE
"other",
#endif
Hi,
On 4/15/20 12:22 PM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 12:11 PM Hans de Goede wrote:
Hi,
On 4/15/20 11:52 AM, Daniel Vetter wrote:
iv. What every SoC subsystem does:
- lcdshadow drivers register drivers
- drm drivers look them up
- if stuff isn't there yet, we
Hi,
On 4/15/20 11:52 AM, Daniel Vetter wrote:
On Wed, Apr 15, 2020 at 11:42 AM Hans de Goede wrote:
Hi All,
Somewhat long mail, so I've divided it into "chapters", sorry.
1. Back ground info
---
First some quick background, some recent Lenovo models have
a
Hi All,
Somewhat long mail, so I've divided it into "chapters", sorry.
1. Back ground info
---
First some quick background, some recent Lenovo models have
a builtin privacy screen which can be turned on/off in software
and the kernel recently has gotten support for this:
https:
Hi,
On 3/31/20 6:44 PM, Jani Nikula wrote:
On Fri, 27 Mar 2020, David Santamaría Rogado wrote:
This patch is still valid as no changes to panel orientation quirks
have been done. Someone can review this to merge?
Cc: Hans.
Looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
Hi,
On 3/26/20 6:55 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 4:10 PM Hans de Goede wrote:
Currently drivers using drm_fbdev_generic_setup() end up with a single
empty aperture in their fb_info struct.
Not having the proper info in the apertures list causes
register_framebuffer to
drm_fb_helper_remove_conflicting_pci_framebuffers().
Add a TODO as a reminder that we need to fix this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_fb_helper.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index
Hi,
On 3/26/20 3:47 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 3:40 PM Hans de Goede wrote:
Hi,
On 3/26/20 2:39 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100
Hi,
On 3/26/20 2:39 PM, Daniel Vetter wrote:
On Thu, Mar 26, 2020 at 2:18 PM Hans de Goede wrote:
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
The vboxvideo driver is missing a call to remove conflicting framebuffers
Hi,
On 3/26/20 12:29 PM, Daniel Vetter wrote:
On Wed, Mar 25, 2020 at 03:43:10PM +0100, Hans de Goede wrote:
The vboxvideo driver is missing a call to remove conflicting framebuffers.
Surprisingly, when using legacy BIOS booting this does not really cause
any issues. But when using UEFI to
driver loads,
changing the pitch).
Adding the missing drm_fb_helper_remove_conflicting_pci_framebuffers()
call fixes this.
Cc: sta...@vger.kernel.org
Fixes: 2695eae1f6d3 ("drm/vboxvideo: Switch to generic fbdev emulation")
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/vbox
Hi,
On 3/19/20 9:14 PM, Simon Ser wrote:
On Thursday, March 19, 2020 7:18 PM, Hans de Goede wrote:
The only way to fix that is to stop Weston from putting non-cursor
content on the cursor plane.
Correct.
Is that something that should be done?
If the hotspot property also had a "dis
Hi,
On 3/19/20 4:16 PM, Pekka Paalanen wrote:
On Thu, 19 Mar 2020 15:30:03 +0100
Hans de Goede wrote:
The only way to fix that is to stop Weston from putting non-cursor
content on the cursor plane.
Correct.
Is that something that should be done?
If the hotspot property also had a
Hi,
On 3/19/20 3:48 PM, Pekka Paalanen wrote:
On Thu, 19 Mar 2020 14:51:41 +0100
Michel Dänzer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2020-03-19 1:54 p.m., Pekka Paalanen wrote:
On Thu, 19 Mar 2020 12:52:14 +0100 Hans de Goede
wrote:
On 3/19/20 12:35 PM, Michel Dänzer
Hi,
On 3/19/20 1:58 PM, Pekka Paalanen wrote:
On Thu, 19 Mar 2020 12:49:27 +0100
Hans de Goede wrote:
Hi,
On 3/19/20 11:00 AM, Pekka Paalanen wrote:
On Wed, 18 Mar 2020 15:28:02 +0100
Hans de Goede wrote:
ATM the Atomic KMS API lacks the ability to set cursor hot-spot
coordinates
Hi,
On 3/19/20 12:35 PM, Michel Dänzer wrote:
On 2020-03-18 4:22 p.m., Simon Ser wrote:
On 3/18/20 3:38 PM, Simon Ser wrote:
1) Letting the VM-viewer window-system draw the cursor as it normally
would draw it.
Why is this important? Can't the VM viewer hide the cursor and use a
sub-surfac
Hi,
On 3/19/20 11:00 AM, Pekka Paalanen wrote:
On Wed, 18 Mar 2020 15:28:02 +0100
Hans de Goede wrote:
ATM the Atomic KMS API lacks the ability to set cursor hot-spot
coordinates. Mutter (and Weston) have tried to emulate this by shifting
the coordinates for where to draw the cursor by the
Hi,
On 3/18/20 4:09 PM, Daniel Vetter wrote:
On Wed, Mar 18, 2020 at 3:29 PM Hans de Goede wrote:
Hi All,
I'm not sure if $subject was a conscious design decision, or an oversight,
but that does not really matter.
ATM the Atomic KMS API lacks the ability to set cursor hot-spot
coordi
Hi,
On 3/18/20 3:38 PM, Simon Ser wrote:
Hi,
1) Letting the VM-viewer window-system draw the cursor as it normally
would draw it.
Why is this important? Can't the VM viewer hide the cursor and use a
sub-surface to manually draw the cursor plane configured by the guest?
Because then moving
Hi,
On 3/18/20 3:28 PM, Hans de Goede wrote:
Hi All,
I'm not sure if $subject was a conscious design decision, or an oversight,
but that does not really matter.
ATM the Atomic KMS API lacks the ability to set cursor hot-spot
coordinates. Mutter (and Weston) have tried to emulate th
Hi All,
I'm not sure if $subject was a conscious design decision, or an oversight,
but that does not really matter.
ATM the Atomic KMS API lacks the ability to set cursor hot-spot
coordinates. Mutter (and Weston) have tried to emulate this by shifting
the coordinates for where to draw the cursor
Hi Lyude,
On 3/7/20 12:54 AM, Lyude Paul wrote:
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede
wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de
g out patches for shortly). Note that I don't have
any DSC displays locally yet, so if someone from AMD could sanity check
this I would appreciate it ♥.
I can confirm that this series fixes only of the 2 FHD monitors on
my Lenovo TB3 gen 2 dock lighting up, thank you!
This series is:
Test
Hi,
On 3/6/20 11:41 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
Hi,
On 3/6/20 11:41 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to
s, see e.g. :
https://bugzilla.redhat.com/show_bug.cgi?id=1809681
https://bugzilla.redhat.com/show_bug.cgi?id=1810070
Let me know if you want me to collect some drm.debug logs, I guess
if you do, you want me to use drm.debug=0x114 ?
Regards,
Hans
Cc: Mikita Lipski
Cc: Alex Deucher
Cc: Sean Pau
[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva
Patch looks good to me:
R
Hi All,
On 2/21/20 6:29 PM, Hans de Goede wrote:
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de
show
the image the right way up on devices with an upside-down mounted panel.
This fixes the image being upside-down on a Teclast X89 tablet.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/
Hi All,
This is a resend of 2 patches which I submitted a while ago, rebased
on top of the latest dinq to fix some conflicts.
The first patch has already been reviewed.
There were some questions about the second patch, which I have answered,
see: https://patchwork.freedesktop.org/patch/345305/?s
ices.
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 55 +-
1 file changed, 1 insertion(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index d07cfad8
fy the timeout when the work is
already scheduled. Which is exactly what we want if the work races
with a plane update.
- Switch to system_long_wq, Hans says on usb2 a plane upload can take
80 ms.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Patch looks
e 5.6 ships. I think rushing things
never is a good idea. So my vote on this goes to just reverting the commit
triggering this for now and taking our time to get this right.
Regards,
Hans
On Wed, 2020-02-26 at 16:15 +0100, Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm maili
Hi,
On 2/26/20 5:05 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede wrote:
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done
Hi,
On 2/26/20 4:29 PM, Alex Deucher wrote:
On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede wrote:
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
Might
Hi Lyude and everyone else,
Lyude I'm mailing you about this because you have done a lot of
work on DP MST, but if this rings a bell to anyone else feel
free to weigh in on this.
I'm currently using a Lenovo X1 7th gen + a Lenovo TB3 gen 2 dock
as my daily rider for testing purposes. When 5.6-rc
the changes, biggest chunk is reindenting the
work fn because it lost its while loop.
Lots of code deleting as consequence all over. Specifically we can
delete the drm_driver.release code now!
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
cking.
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/gm12u320.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ti
Hi,
On 2/21/20 10:03 PM, Daniel Vetter wrote:
Only drops the drm_dev_put, but hey a few lines!
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u
tter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u320.c | 18 +++---
1 file changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/dr
Hi,
On 2/21/20 10:02 PM, Daniel Vetter wrote:
With this we can drop the final kfree from the release function.
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file
Hi All,
I'm resending this patch since the discussion on it has fallen
silent for a while now.
Last time I posted it, the discussion seemed to be heading towards
agreement that this is the right thing to do, but I never got an
ack or some such.
See here for the discussion from last time:
https:/
commandline so that it can
pick that mode over the mode which is marked as DRM_MODE_TYPE_PREFERRED.
This commit sets the DRM_MODE_TYPE_USERDEF flag on the matching mode, just
as we would do on the user-specified mode when no matching probed mode is
found.
Signed-off-by: Hans de Goede
---
drivers/gpu
s not matter in this case.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_quirks.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 399b1542509f..54dba152ead8 100644
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c
:
Reviewed-by: Hans de Goede
Regards,
Hans
Thomas Zimmermann (4):
drm: Document struct drm_crtc_state.no_vblank for faking VBLANK events
drm/ast: Set struct drm_crtc_state.no_vblank in atomic_check()
drm/cirrus: Let DRM core send VBLANK events
drm/simple-kms: Let DRM core send
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Hans de Goede (changes in v2):
Rename
ink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index de5031c4aa49..f6
Hi,
On 03-01-2020 20:38, Rodrigo Vivi wrote:
On Mon, Dec 16, 2019 at 12:51:58PM +0100, Hans de Goede wrote:
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugL
Hi Rodrigo,
Thank you for the review.
On 02-01-2020 19:17, Rodrigo Vivi wrote:
On Mon, Dec 16, 2019 at 12:51:57PM +0100, Hans de Goede wrote:
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into
n 16-12-2019 12:51, Hans de Goede wrote:
Hi All,
This is a resend of the last 2 remaining patches of my series for adding
support for specifying panel_orientation on the kernel cmdline.
I've already pushed the other 11 patches which were mostly cleanups /
bug-fixes to the cmdline-parsing code
Hi,
On 30-12-2019 14:31, Linus Walleij wrote:
On Mon, Dec 16, 2019 at 9:51 PM Hans de Goede wrote:
Currently only the drivers/pinctrl/devicetree.c code allows registering
pinctrl-mappings which may later be unregistered, all other mappings
are assumed to be permanent.
Non-dt platforms may
Hi All,
Here is v2 of my patch-series to make the
i915 code control the SoC panel- and backlight-enable GPIOs on Bay Trail
devices when the VBT indicates that the SoC should be used for backlight
control. This fixes the panel not lighting up on various devices when
booted with a HDMI monitor conne
its
pinctrl_register_mappings counter-part and exports it.
Together these 2 changes will allow non-dt platform code to
register pinctrl-mappings from modules without breaking things on
module unload (as they can now unregister the mapping on unload).
Signed-off-by: Hans de Goede
---
Changes in v2
, this will also allow us to extend
it with GPIOs from other sources when necessary.
Acked-by: Linus Walleij
Reviewed-by: Andy Shevchenko
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 23 +++-
drivers/mfd
external monitor connected over HDMI.
Changes in v2:
- Call intel_dsi_get_hw_state() to check if the panel is on instead of
relying on the current_mode pointer
Reviewed-by: Linus Walleij
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi.h | 2 +-
drivers/gpu/drm/i915
Point of View MOBII TAB-P1005W
Terra Pad 1061
Yours Y8W81
Reviewed-by: Linus Walleij
Reviewed-by: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi.h | 3 +-
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 64
2 files changed, 66
: Ville Syrjälä
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi.h | 2 +
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 46 +++-
drivers/gpu/drm/i915/display/vlv_dsi.c | 27 +---
3 files changed, 48 insertions(+), 27 deletions(-)
diff --git a
d-by: Andy Shevchenko
Acked-by: Rafael J. Wysocki
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_lpss.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 70f740b09684..db18df6cb330 100644
--- a/drivers/acpi/ac
ntroller to "pwm_pmic_backlight" so that the i915 driver can do a
pwm_get() for the right controller depending on the VBT bit, instead of
the i915 driver relying on a "pwm_backlight" lookup getting registered
which magically points to the right controller.
Acked-by: Jani Nikul
Hi All,
Somehow the CI system did not pick up this series the first time, there
are no test results recorded for it:
https://patchwork.freedesktop.org/series/69685
So this is a resend for CI to do its thing. As soon as CI is happy with
this I will push this to drm-intel-next-queued.
Regards,
Ha
ed-by: Jani Nikula
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel
Hi,
On 16-12-2019 14:39, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 10:33:07PM +0100, Hans de Goede wrote:
Some devices with a builtin panel have the panel mounted upside down,
this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT
block.
We store this info in dev_priv
Hi,
On 16-12-2019 15:14, Ville Syrjälä wrote:
On Mon, Dec 16, 2019 at 02:51:54PM +0100, Hans de Goede wrote:
Hi,
Thank you for the reviews.
On 16-12-2019 14:45, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
When the LCD has not been turned on by the
Hi,
On 16-12-2019 15:04, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:10PM +0100, Hans de Goede wrote:
On Bay Trail devices the MIPI power on/off sequences for DSI LCD panels
do not control the LCD panel- and backlight-enable GPIOs. So far, when
the VBT indicates we should use the SoC
Hi,
On 16-12-2019 14:56, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
Move the Crystal Cove PMIC panel GPIO lookup-table from
drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
The moved looked-up table is adding a GPIO lookup to the i915 PCI
device
Hi,
Thank you for the reviews.
On 16-12-2019 14:45, Ville Syrjälä wrote:
On Sun, Dec 15, 2019 at 05:38:08PM +0100, Hans de Goede wrote:
When the LCD has not been turned on by the firmware/GOP, because e.g. the
device was booted with an external monitor connected over HDMI, we should
not turn
Hi,
On 16-12-2019 13:16, Linus Walleij wrote:
On Mon, Dec 16, 2019 at 12:11 PM Hans de Goede wrote:
Ugh, taking one last look at the "pinctrl: Export pinctrl_unregister_mappings"
patch it is no good, sorry.
Ooops!
Linus, can you please drop this from your -next ?
Sure, done.
Hi,
On 16-12-2019 13:16, Andy Shevchenko wrote:
On Sun, Dec 15, 2019 at 05:38:09PM +0100, Hans de Goede wrote:
Move the Crystal Cove PMIC panel GPIO lookup-table from
drivers/mfd/intel_soc_pmic_core.c to the i915 driver.
The moved looked-up table is adding a GPIO lookup to the i915 PCI
device
Use intel_panel_compute_brightness() from pwm_setup_backlight() so that
we correctly take i915_modparams.invert_brightness and/or
QUIRK_INVERT_BRIGHTNESS into account when setting + getting the initial
brightness value.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_panel.c
Hi All,
Here is a resend of my series to fix the brightness being inverted on
Thundersoft TST178 tablets. This resend is based on top of dinq so that
the CI can properly test it. No changes other then the rebase on top of
dinq.
Regards,
Hans
___
dri-d
s not matter in this case.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_quirks.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c
b/drivers/gpu/drm/i915/display/intel_quirks.c
index 399b1542509f..54dba152ead8 100644
If the new video=... panel_orientation option is set for a connector, honor
it and setup a matching "panel orientation" property on the connector.
BugLink: https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/83
Acked-by: Maxime Ripard
Signed-off-by: Hans de Goede
---
d
Hi All,
This is a resend of the last 2 remaining patches of my series for adding
support for specifying panel_orientation on the kernel cmdline.
I've already pushed the other 11 patches which were mostly cleanups /
bug-fixes to the cmdline-parsing code and where all acked by Maxime
to drm-misc-ne
From: Derek Basehore
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Hans de Goede (changes in v2):
Rename
Hi,
On 16-12-2019 11:26, Linus Walleij wrote:
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
Linus, this series starts with the already discussed pinctrl change to
export the function to unregister a pinctrl-map. We can either merge this
through drm-intel, or you could pick it up and
Hi,
On 16-12-2019 11:26, Linus Walleij wrote:
On Sun, Dec 15, 2019 at 5:38 PM Hans de Goede wrote:
Linus, this series starts with the already discussed pinctrl change to
export the function to unregister a pinctrl-map. We can either merge this
through drm-intel, or you could pick it up and
which magically points to the right controller.
Signed-off-by: Hans de Goede
---
drivers/mfd/intel_soc_pmic_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
For my own reference:
Acked-for-MFD-by: Lee Jones
As mentioned in the cover-letter, to avoid breaking
show
the image the right way up on devices with an upside-down mounted panel.
This fixes the image being upside-down on a Teclast X89 tablet.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/
let,
so using the generic intel_dsi_get_panel_orientation() helper there does
the right thing without needing any extra readback of hw state.
This commit removes the special handling of the panel orientation for
DSI panels on BYT/CHT devices, bringing the handling in line with the
handling of DSI panels on other devices
Hi,
On 11-12-2019 18:38, Hans de Goede wrote:
Hi,
I know these kinda patches are sorta trivial, still I prefer to get an
Acked-by before pushing this to drm-misc-next. Can someone review this please?
Alternative I guess we could agree that pushing patches which just add a dmi
quirk to
1001 - 1100 of 2016 matches
Mail list logo
