e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/dd79a51e/attachment.html>
When division of source and destination width yields the
scaling factor for the x-coordinate, then it should be
source/destination _height_ for y.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/
The hardware accepts scaling factors formatted in a
fixed-point format. The current macro casts to integer
first, then multiplies by the fp conversion factor.
This does not make any sense. In particular, truly
'fractional' inputs, like 1.5, won't work that way.
Signed-off-by: Tobias Jakobi
---
The right-bottom register isn't set correctly.
Looks like a copy-and-paste error.
Signed-off-by: Tobias Jakobi
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 0b14618..a565910 100644
--- a/exynos
When division of source and destination width yields the
scaling factor for the x-coordinate, then it should be
source/destination _height_ for y.
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index a5
The hardware accepts scaling factors formatted in a
fixed-point format. The current macro casts to integer
first, then multiplies by the fp conversion factor.
This does not make any sense. In particular, truly
'fractional' inputs, like 1.5, won't work that way.
---
exynos/fimg2d.h | 2 +-
1 file
The right-bottom register isn't set correctly.
Looks like a copy-and-paste error.
---
exynos/exynos_fimg2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
index 0b14618..a565910 100644
--- a/exynos/exynos_fimg2d.c
+++ b/exynos/e
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/f3365e95/attachment.html>
Hi
On Thu, May 29, 2014 at 7:25 PM, Daniel Vetter
wrote:
> Drivers really have no business touching these. Noticed because
> exynose _did_ touch the vblank off delay, which could potentially
> affect other drivers.
>
> drm_debug is an exception since it's used in macros and inline
> functions.
>
The GMUX doesn't appear to switch instantly, which can trigger problems in
panel detection and setup. Wait for an interrupt or 200msec, whichever comes
first.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 12
1 file changed, 12 insertions(+)
diff --git a/dr
The Apple GMUX can cut power to the discrete GPU, so should declare this
to the vga_switcheroo core.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/apple-gmux.c
b/drivers/platform/x86/apple-gmux.c
ind
Registering the handler after both GPUs will trigger a DDC switch for
connector reprobing. This will oops if apple_gmux_data hasn't already been
assigned. Reorder the code to do that.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 10 ++
1 file changed, 6 insertio
We can switch DDC pins in a way that ought (with luck) to work for LVDS.
This isn't sufficient for eDP, which is addressed in later patches.
Signed-off-by: Matthew Garrett
---
drivers/platform/x86/apple-gmux.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/platform/x86/
We need to force the previously active device to reprobe its connectors
when we switch in order to allow it to give up connectors that are no
longer in use.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_switcheroo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/vga/
We may not know whether the platform supports dynamic PM of GPUs until the
switcheroo handler is registered. Add an enable() callback for clients and
another entry point to switcheroo in order to permit them to set dynamic PM
appropriately.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_
Most switcheroo setups attach power management to one of the GPUs. This is
not always the case, so provide a mechanism for handlers to declare that
they can change the power state of GPUs and permit drivers to obtain this
information.
Signed-off-by: Matthew Garrett
---
drivers/gpu/vga/vga_switch
Not all MUXes allow us to connect the panel data channel to a GPU without
handing over the entire panel and triggering additional flickering during
boot. We only need to do this in order to probe for data that the first
GPU driver has already identified, so add some functions for stashing that
data
Add a command line option in order to allow the user to provide a perferred
GPU at boot time.
Signed-off-by: Matthew Garrett
---
Documentation/kernel-parameters.txt | 5 +
drivers/gpu/vga/vga_switcheroo.c| 29 +
2 files changed, 34 insertions(+)
diff --git a
If display MUXing is handled by an external driver, the handler may not
initialise until some time after the graphics drivers originally bound. If
the driver is unable to detect some drivers unless appropriately MUXed, this
will cause problems. This patch adds a callback to allow switcheroo to
retr
From: Seth Forshee
During graphics driver initialization its useful to be able to mux only
the DDC to the inactive client in order to read the EDID. Add a
switch_ddc callback to allow capable handlers to provide this
functionality, and add vga_switcheroo_switch_ddc() to allow DRM to mux
only the
The Apple GMUX switcheroo code doesn't really work that well - there's no
straightforward way to ensure that drivers are loaded in the correct order,
and no mechanism to probe displays without performing a full switch. This
patchset adds infrastructural support to switcheroo and functionality to
GM
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/bc0d73a5/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/3e850440/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/2b7c7a9d/attachment-0001.html>
re receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140601/c00e4855/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #24 from Tasev Nikola ---
The new ref_div_max = max(min(100 / post_div, ref_div_max), 1u);
works fine with my Belinea 1600x1200 screen.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=74751
--- Comment #26 from Tasev Nikola ---
(In reply to Daniel Vetter from comment #25)
> Created attachment 137721 [details]
> resume fbcon later
>
> Hm, somehow forgotten to attach this yesterday. Please test this patch
> instead of any reverts.
Th
On 01.06.2014 03:14, Tobias Jakobi wrote:
> Hello Tomasz!
>
>
> Tomasz Figa wrote:
>> However looking at libdrm repo history, your patches don't seem to
>> follow formatting guidelines used there: they lack commit messages
>> (which should say what is changed and why) and your signed-off-by tags.
Hello Tomasz!
Tomasz Figa wrote:
> However looking at libdrm repo history, your patches don't seem to
> follow formatting guidelines used there: they lack commit messages
> (which should say what is changed and why) and your signed-off-by tags.
Originally I sent these to Rob Clark (with Inki Dae
Hi Tobias,
First of all, thanks for spotting those issues and sending patches.
However looking at libdrm repo history, your patches don't seem to
follow formatting guidelines used there: they lack commit messages
(which should say what is changed and why) and your signed-off-by tags.
Also it is
There is a risk that the variable will be used without being initialized.
This was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist
---
drivers/gpu/drm/radeon/r600_cp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
;acpi-video: Add an acpi_video_unregister_backlight function"
> > patch, which you've applied to your linux-next branch already.
> >
> > As well as on the 2nd patch in this series:
> > "backlight: Add backlight device (un)registration notification"
>
32 matches
Mail list logo
