On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote:
> On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> > Hi,
> >
> > I sent this individual i915 patch to our CI, and it is passing on
> > all platforms:
> >
> > https://patchwork.freedesktop.org/series/34822/
> >
> > Is it ok if I merge this to dr
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
> On 12/12/17 11:19, Tvrtko Ursulin wrote:
> >
> > On 11/12/2017 21:05, Daniel Vetter wrote:
> > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > > On 11/12/2017 10:50, Joonas Lahtinen wrote:
> > > > > + Dani
On Tue, Dec 12, 2017 at 03:44:07PM +, Marius-cristian Vlad wrote:
> drm_mode_create_lease_ioctl() -> drm_lease_create()
>
> drm_lease_create() -> fails and drm_master_put() is called
> twice: once in drm_lease_create() and once in
> drm_mode_create_lease_ioctl().
>
> From drm_mode_create_leas
There are a set of values in the drm_display_info structure for each
connector which hold information derived from EDID. These are computed
in drm_add_display_info. Before this patch, that was only called in
drm_add_edid_modes. This meant that they were only set when EDID was
present and never rese
drm_mode_config_cleanup() might be called from a workqueue context (for
example in error path handling of deferred probe), so it must not call
flush_scheduled_work(), because it would deadlock in such case. Replace
that call with explicit counting of the scheduled connector free works
and waiting u
https://bugs.freedesktop.org/show_bug.cgi?id=104159
Christoph Haag changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104200
--- Comment #1 from Vedran Miletić ---
Created attachment 136134
--> https://bugs.freedesktop.org/attachment.cgi?id=136134&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.___
Quoting Marek Szyprowski (2017-12-13 08:57:20)
> drm_mode_config_cleanup() might be called from a workqueue context (for
> example in error path handling of deferred probe), so it must not call
> flush_scheduled_work(), because it would deadlock in such case. Replace
> that call with explicit count
Hello Morimoto-san,
Thank you for the patch.
On Wednesday, 6 December 2017 08:05:38 EET Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> In general, PLL has VCO (= Voltage controlled oscillator),
> one of the very important electronic feature called as "jitter"
> is related to this VCO.
>
Well I don't have an igt test for it, but here's what happens when I try to
create a new lease which hasn't been revoked (so, it's currently created but
not revoked and
trying to create a new one):
[ 210.347052] [drm:drm_ioctl] pid=3309, dev=0xe200, auth=1,
DRM_IOCTL_MODE_CREATE_LEASE
[ 210.34
Am 13.12.2017 um 03:06 schrieb He, Roger:
That is a bug fix, isn't it? If yes maybe add CC:stable and commit it
first before all other patches.
Fortunately so far there is no issue directly resulted from that.
Yeah, but that is irrelevant. Patches are classified as fix if they fix
so
Hi Pavel,
On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote:
> On Mon 2017-12-04 11:50:40, Jose Abreu wrote:
> >
> > Hi Alexey,
> >
> > On 04-12-2017 11:32, Alexey Brodkin wrote:
> > >
> > > My first [probably incorrect] assumption is Xserver requires fbdev
> > > (/dev/fbX)
> > > and it ca
On 12/12/2017 04:32 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2017-12-12-16-32 has been uploaded to
>
>http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of m
libdrm_.so are moved to the vendor partition (/vendor/lib or
/system/vendor/lib if there is no dedicated vendor partition), since
they are vendor-specific extension that must not be in the system
partition which should be generic.
libdrm.so (which is generic) is built/installed twice: once to
/ven
On 12/12/2017 9:04 AM, Joonas Lahtinen wrote:
> Hi,
>
> I sent this individual i915 patch to our CI, and it is passing on all
> platforms:
>
> https://patchwork.freedesktop.org/series/34822/
>
> Is it ok if I merge this to drm-tip already?
As long as you have this change in your tree, it shoul
Hi Zhenyu,
Quoting Zhenyu Wang :
On 2017.12.09 00:37:59 -0600, Gustavo A. R. Silva wrote:
In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge
number as fmt is of type u32, hence there is an out-of-bounds read when
using fmt as an index for array skl_pixel_formats at line
On Tue, Dec 12, 2017 at 03:37:21PM +0100, Hans Verkuil wrote:
> Hi Russell,
>
> On 08/12/17 12:59, Russell King - ARM Linux wrote:
> > On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
> >> On 12/06/17 13:35, Russell King wrote:
> >>> We no longer use the CEC client to access the CEC p
Am 13.12.2017 um 06:17 schrieb Roger He:
allow_reserved_eviction: Allow eviction of reserved BOs
resv: Reservation object to allow reserved evictions with
Change-Id: I01ea482e8c7470014196eb218e2ff8913306eef0
Signed-off-by: Roger He
Reviewed-by: Christian König
---
include/drm/ttm/ttm_bo_
Am 13.12.2017 um 06:17 schrieb Roger He:
Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
Signed-off-by: Roger He
We should supply the resv object in amdgpu_cs_bo_validate() as well, or
otherwise the deleted object handling won't work as desired any more.
Apart from that looks good to m
On 2017-12-13 06:17 AM, Roger He wrote:
> Change-Id: I0c6571c2a64e6c5bdad80ccbcccb40eba1c20b4e
> Signed-off-by: Roger He
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
> b/dri
Am 13.12.2017 um 06:17 schrieb Roger He:
Change-Id: I0c6ece0decd18d30ccc94e5c7ca106d351941c62
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
i
Hi Hans,
On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
> picture. Some
> digging found that there is no check against the upper pixelclock limit of
> the HDMI
> output, so X selects a 4kp60 format at 594
On Wed, Dec 13, 2017 at 09:18:55AM +, Marius-cristian Vlad wrote:
> Well I don't have an igt test for it, but here's what happens when I try to
> create a new lease which hasn't been revoked (so, it's currently created but
> not revoked and
> trying to create a new one):
>
> [ 210.347052] [d
On Wed, Dec 13, 2017 at 09:57:20AM +0100, Marek Szyprowski wrote:
> drm_mode_config_cleanup() might be called from a workqueue context (for
> example in error path handling of deferred probe), so it must not call
> flush_scheduled_work(), because it would deadlock in such case. Replace
> that call
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single cleanup work, so that we can only
flush that one and don'
On Wed, 29 Nov 2017, Gustavo Padovan wrote:
> 2017-11-24 Sean Paul :
>
>> On Thu, Nov 23, 2017, 7:12 AM Jani Nikula wrote:
>>
>> > I'm juggling too many things, and drm-misc maintenance is one that I
>> > keep dropping on the floor. Admit reality and remove myself as
>> > maintainer. This still
Quoting Daniel Vetter (2017-12-13 10:45:53)
> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> that again fails, and we try to flush the overall system_wq (to get
> all the delayed connectore cleanup work_struct completed), we
> deadlock.
>
> Fix this by using just a single c
On 13/12/17 11:30, Maxime Ripard wrote:
> Hi Hans,
>
> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
>> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
>> picture. Some
>> digging found that there is no check against the upper pixelclock limit of
>> the
Hi,
On 13-12-2017 11:05, Hans Verkuil wrote:
> On 13/12/17 11:30, Maxime Ripard wrote:
>> Hi Hans,
>>
>> On Fri, Dec 08, 2017 at 04:48:47PM +0100, Hans Verkuil wrote:
>>> When I connected my cubieboard running 4.15-rc1 to my 4k display I got no
>>> picture. Some
>>> digging found that there is no
Hi Daniel,
On 2017-12-13 11:45, Daniel Vetter wrote:
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single c
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single cleanup work, so that we can only
flush that one and don'
Hi Daniel,
On 2017-12-13 13:49, Daniel Vetter wrote:
PROBE_DEFER also uses system_wq to reprobe drivers, which means when
that again fails, and we try to flush the overall system_wq (to get
all the delayed connectore cleanup work_struct completed), we
deadlock.
Fix this by using just a single c
Quoting Daniel Vetter (2017-12-13 12:49:36)
> PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> that again fails, and we try to flush the overall system_wq (to get
> all the delayed connectore cleanup work_struct completed), we
> deadlock.
>
> Fix this by using just a single c
On Wed, Dec 13, 2017 at 01:48:28AM +, Hyun Kwon wrote:
> Hi Laurent,
>
> Thanks for the comment.
>
> > -Original Message-
> > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> > Sent: Monday, December 11, 2017 6:02 AM
> > To: Hyun Kwon
> > Cc: Daniel Vetter ; Jani N
On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-12-13 12:49:36)
> > PROBE_DEFER also uses system_wq to reprobe drivers, which means when
> > that again fails, and we try to flush the overall system_wq (to get
> > all the delayed connectore cleanup work_st
Quoting Daniel Vetter (2017-12-13 08:17:17)
> On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
> > On 12/12/17 11:19, Tvrtko Ursulin wrote:
> > >
> > > On 11/12/2017 21:05, Daniel Vetter wrote:
> > > > On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
> > > > > On 1
On Wed, Dec 13, 2017 at 12:44:26AM -0800, Keith Packard wrote:
> There are a set of values in the drm_display_info structure for each
> connector which hold information derived from EDID. These are computed
> in drm_add_display_info. Before this patch, that was only called in
> drm_add_edid_modes.
On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> The code has an ifdef and uses two functions to either init the bare
> spinlock or init it and set a lock-class. It is possible to do the same
> thing without an ifdef.
> With this patch (in debug case) we first use the "default"
This patch adds support for AUO G104SN02 V2 800x600 10.4" panel to DRM
simple panel driver.
Signed-off-by: Christoph Fritz
Signed-off-by: Stefan Riedmueller
---
.../bindings/display/panel/auo,g104sn02.txt| 7 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
On Fri, Dec 08, 2017 at 12:31:08PM +, Russell King wrote:
> Add the defacto-standard "iturbt_709" property to the overlay plane to
> control the YUV to RGB colorspace conversion. This is mutually
> exclusive with the CSC_YUV CRTC property - the last property to be set
> determines the resultin
On 13/12/17 08:17, Daniel Vetter wrote:
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
On 12/12/17 11:19, Tvrtko Ursulin wrote:
On 11/12/2017 21:05, Daniel Vetter wrote:
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wrote:
On 11/12/2017 10:50, Joonas Lahtinen wr
On 13/12/17 13:35, Chris Wilson wrote:
Quoting Daniel Vetter (2017-12-13 08:17:17)
On Tue, Dec 12, 2017 at 02:33:38PM +, Lionel Landwerlin wrote:
On 12/12/17 11:19, Tvrtko Ursulin wrote:
On 11/12/2017 21:05, Daniel Vetter wrote:
On Mon, Dec 11, 2017 at 02:38:53PM +, Tvrtko Ursulin wro
Now that we have everything in place, we can start enabling the frontend.
This is more difficult than one would assume since there can only be one
plane using the frontend per-backend.
We therefore need to make sure that the userspace will not try to setup
multiple planes using it, since that woul
The display frontend is an hardware block that can be used to implement
some more advanced features like hardware scaling or colorspace
conversions. It can also be used to implement the output format of the VPU.
Let's create a minimal driver for it that will only enable the hardware
scaling featur
We will need to store some additional data in the future to the state.
Create a custom plane state that will embed those data, in order to store
the pipe or whether or not that plane should use the frontend.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_layer.c | 48 ++
The function converting the DRM format to its equivalent in the backend
registers was assuming that we were having a plane.
However, we might want to use that function when setting up a plane using
the frontend, in which case we will not have a plane associated to the
backend's layer. Yet, we stil
Now that we have a driver, we can make use of it. This is done by
adding a flag to our custom plane state that will trigger whether we should
use the frontend on that particular plane or not.
The rest is just plumbing to set up the backend to not perform the DMA but
receive its data from the front
Setup the line stride in the buffer setup function, since it's tied to the
buffer itself, and is not needed when we do not set the buffer in the
backend.
This is for example the case when using the frontend and then routing its
output to the backend.
Signed-off-by: Maxime Ripard
---
drivers/gpu
We have some restrictions on what the planes and CRTC can provide that are
tied to only one generation of display engines.
For example, on the first generation, we can only have one YUV plane or one
plane that uses the frontend output.
Let's allow our engines to provide an atomic_check callback t
The display frontend can be used to do hardware scaling, colorspaces
conversion or to implement the buffer format output by the Cedar VPU.
Since we're starting to have some support for it in the DRM driver, let's
enable its DT node.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a33.d
Hi,
This is a first serie to enable the display engine frontend.
This hardware block is found in the first generation Display Engine from
Allwinner. Its role is to implement more advanced features that the
associated backend, even though the backend alone can be used (and was used
so far) for bas
On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-13 16:00:49 [+0200], Joonas Lahtinen wrote:
> > On Thu, 2017-11-30 at 16:19 +0100, Sebastian Andrzej Siewior wrote:
> > > The code has an ifdef and uses two functions to either init the bare
> > > spinlock or init it a
Hi Russell,
On 8 December 2017 at 12:31, Russell King wrote:
> Add the defacto-standard "iturbt_709" property to the overlay plane to
> control the YUV to RGB colorspace conversion. This is mutually
> exclusive with the CSC_YUV CRTC property - the last property to be set
> determines the resulti
On 13/12/2017 16:33, Maxime Ripard wrote:
> Setup the line stride in the buffer setup function, since it's tied to the
> buffer itself, and is not needed when we do not set the buffer in the
> backend.
>
> This is for example the case when using the frontend and then routing its
> output to the ba
On 13/12/2017 16:33, Maxime Ripard wrote:
> The function converting the DRM format to its equivalent in the backend
> registers was assuming that we were having a plane.
>
> However, we might want to use that function when setting up a plane using
> the frontend, in which case we will not have a p
On 13/12/2017 16:33, Maxime Ripard wrote:
> We will need to store some additional data in the future to the state.
> Create a custom plane state that will embed those data, in order to store
> the pipe or whether or not that plane should use the frontend.
>
> Signed-off-by: Maxime Ripard
> ---
>
On 13/12/2017 16:33, Maxime Ripard wrote:
> We have some restrictions on what the planes and CRTC can provide that are
> tied to only one generation of display engines.
>
> For example, on the first generation, we can only have one YUV plane or one
> plane that uses the frontend output.
>
> Let's
On 13/12/2017 16:33, Maxime Ripard wrote:
> The display frontend is an hardware block that can be used to implement
> some more advanced features like hardware scaling or colorspace
> conversions. It can also be used to implement the output format of the VPU.
>
> Let's create a minimal driver for
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #10 from Jerry Zuo ---
(In reply to dwagner from comment #9)
> Bad news: Tried amd-staging-drm-next as of commit
> 367a3d2bdc27fd1d23be9ea75cec34b52297184d, which does include the commit
> https://cgit.freedesktop.org/~agd5f/linux/co
On 13/12/2017 16:33, Maxime Ripard wrote:
> Now that we have a driver, we can make use of it. This is done by
> adding a flag to our custom plane state that will trigger whether we should
> use the frontend on that particular plane or not.
>
> The rest is just plumbing to set up the backend to not
On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote:
> Hi Russell,
>
> On 8 December 2017 at 12:31, Russell King wrote:
>> Add the defacto-standard "iturbt_709" property to the overlay plane to
>> control the YUV to RGB colorspace conversion. This is mutually
>> exclusive with the CSC_YUV CRTC
On 13/12/2017 16:33, Maxime Ripard wrote:
> Now that we have everything in place, we can start enabling the frontend.
> This is more difficult than one would assume since there can only be one
> plane using the frontend per-backend.
>
> We therefore need to make sure that the userspace will not tr
Generated using make header_install.
Generated from drm-intel-next-queued commit
53ff2641a817099e1c6d1aef409ba004c3a9f1ea
Signed-off-by: Michał Winiarski
---
include/drm/i915_drm.h | 215 ++---
1 file changed, 202 insertions(+), 13 deletions(-)
diff
On Wed, Dec 13, 2017 at 11:12:18AM -0500, Ilia Mirkin wrote:
> On Wed, Dec 13, 2017 at 10:41 AM, Daniel Stone wrote:
> > Hi Russell,
> >
> > On 8 December 2017 at 12:31, Russell King
> > wrote:
> >> Add the defacto-standard "iturbt_709" property to the overlay plane to
> >> control the YUV to RG
Op 13-12-17 om 17:19 schreef Leo Li:
> Hi Daniel, Maarten,
>
> Just digging an old thread out of the grave:
> https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
>
> It's suppose to fix a memory leak on the drm_commit object during
> non-blocking commits. Within drm_atomic_help
On Wed, Dec 13, 2017 at 06:36:33PM +0100, Sebastian Andrzej Siewior wrote:
> +peterz
> context: http://www.spinics.net/lists/intel-gfx/msg149011.html
>
> On 2017-12-13 17:37:21 [+0200], Joonas Lahtinen wrote:
> > On Wed, 2017-12-13 at 16:06 +0100, Sebastian Andrzej Siewior wrote:
> > > On 2017-12-
This case can been seen when creating the lease with the same objects passed.
[ 605.515097] 2 locks held by testapp/3337:
[ 605.519027] #0: (&dev->mode_config.idr_mutex){..}, at:
[] drm_mode_create_lease_ioctl+0x384/0x858
[ 605.530045] #1: (&dev->mode_config.idr_mutex){..}, at:
[]
On 2017-12-13 12:23 PM, Maarten Lankhorst wrote:
Op 13-12-17 om 17:19 schreef Leo Li:
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object during
no
https://bugs.freedesktop.org/show_bug.cgi?id=104248
Bug ID: 104248
Summary: Black screen after switching refresh rate from 144 Hz
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104248
--- Comment #1 from Thomas Lange ---
Created attachment 136149
--> https://bugs.freedesktop.org/attachment.cgi?id=136149&action=edit
Output of xrandr
If you need more information, let me know.
--
You are receiving this mail because:
You are
Hi,
I think this series is quite poorly documented. We should have a log
message explaining the purpose of the commit.
Also since it's not obvious what the series is attempting to achieve,
please add a 0/X series header message..
/Thomas
On 12/12/2017 10:33 AM, Roger He wrote:
on_alloc_sta
https://bugs.freedesktop.org/show_bug.cgi?id=104248
--- Comment #2 from Thomas Lange ---
Created attachment 136150
--> https://bugs.freedesktop.org/attachment.cgi?id=136150&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.__
This allows showing multiple logos, each in its own position,
relative to the eight screen corners.
Signed-off-by: Max Staudt
---
drivers/video/fbdev/core/bootsplash_render.c | 136 ++-
include/uapi/linux/bootsplash_file.h | 45 -
2 files changed, 178 ins
After exiting a KD_GRAPHICS program and falling back to the text
console, a previously enabled splash needs to be fully redrawn.
This corner case was introduced with selective re-drawing while
implementing animations.
Without this patch, the following happens:
1. Switch to a text console
2. Enab
This is the initial prototype for a lean Linux kernel bootsplash.
It works by replacing fbcon's FB manipulation routines (such as
bitblit, tileblit) with dummy functions, effectively disabling text
output, and drawing the splash directly onto the FB device.
As it is now, it will show a black scre
Signed-off-by: Max Staudt
Reviewed-by: Oliver Neukum
---
drivers/video/fbdev/core/fbcon.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 9a39a6fcfe98..8a9c67e1c5d8 100644
--- a/drivers/video/fbdev/core/fbc
Dear fbdev and fbcon developers,
Thank you very much for your input for the first patch series.
I've included your feedback into this second roll, and kindly ask for
your opinion on the new patch series.
Changes from v1 to v2:
+ Added a user space tool to create splash theme files
+ Bumped t
Signed-off-by: Max Staudt
---
.../ABI/testing/sysfs-platform-bootsplash | 11 ++
Documentation/bootsplash.rst | 177 +
MAINTAINERS| 2 +
3 files changed, 190 insertions(+)
create mode 100644 Documentati
Also, mention this in the bootsplash documentation.
Signed-off-by: Max Staudt
---
Documentation/bootsplash.rst | 10 ++
tools/bootsplash/.gitignore| 3 ++
tools/bootsplash/ajax-loader.gif | Bin 0 -> 3208 bytes
tools/bootsplash/bootsplash-tux.sh | 66 +
Each 'picture' in the splash file can consist of multiple 'blobs'.
If animation is enabled, these blobs become the frames of an animation,
in the order in which they are stored in the file.
Note: There is only one global timer, so all animations happen at
the same frame rate. It doesn't rea
Framebuffers with deferred I/O need to be flushed to the screen
explicitly, since we use neither the mmap nor the file I/O abstractions
that handle this for userspace FB clients.
Example: xenfb
Some framebuffer drivers implement lazy access to the screen without
actually exposing a fbdefio interf
Load logo(s) from a file and render them in the center of the screen.
This removes the "black screen" functionality, which can now be emulated
by providing a splash file with no pictures and a black background.
Signed-off-by: Max Staudt
---
MAINTAINERS| 1 +
Let's disable the splash if the user presses ESC or F1-F12 on a VT.
The F1-F12 check is to disable the splash on VT switches.
Signed-off-by: Max Staudt
---
drivers/tty/vt/keyboard.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/tty/vt/keyboard.c b/drivers
Signed-off-by: Max Staudt
---
MAINTAINERS | 1 +
tools/bootsplash/.gitignore | 1 +
tools/bootsplash/Makefile| 9 +
tools/bootsplash/bootsplash-packer.c | 471 +++
4 files changed, 482 insertions(+)
create mode 1
When the user requests a clean TTY via the SAK SysRq, that means he
really wants to use the console.
Let's disable the bootsplash, even if the request is not on a VT, as
the user probably knows what he's doing and it's more helpful to get
out of his way.
Signed-off-by: Max Staudt
Reviewed-by: Ol
Users can use this to replace their splash screen at runtime by writing
a path and filename to /sys/devices/platform/bootsplash.0/load_file and
making sure the splash is enabled.
Notes:
- The path has to be a path in /lib/firmware since request_firmware()
is used to fetch the data.
- When
Unfortunately I've forgotten to rebase this patchset to 4.15, so it still
builds on top of 4.14.
I'll rebase it for the next roll.
Max
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Daniel, Maarten,
Just digging an old thread out of the grave:
https://lists.freedesktop.org/archives/dri-devel/2017-August/150495.html
It's suppose to fix a memory leak on the drm_commit object during
non-blocking commits. Within drm_atomic_helper_setup_commit, a reference
to the commit objec
CFL was missing from intel_early_ids[]. The PCI ID needs to be there to
allow the memory region to be stolen, otherwise we could have RAM being
arbitrarily overwritten if for example we keep using the UEFI framebuffer,
depending on how BIOS has set up the e820 map.
Fixes: b056f8f3d6b9 ("drm/i915/c
A couple patches aimed in particular at simplifying firmware debugging.
The first patch adds some debugfs to dump out state, as well as a
debugfs file that can be written to trigger GPU reset and firmware
reloading.
The second patch adds a new SUBMIT ioctl flag to allow userspace to
submit cmdstr
Add some debugfs to dump out PFP and ME microcontroller state, as well
as some of the queues (MEQ and ROQ). Also add a debugfs file to trigger
a GPU reset (and reloading the firmware on next submit).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/Makefile | 2 +
drivers/gpu/dr
This flags cause cmdstream to be executed from the ringbuffer (RB)
instead of IB1. Normally not something you'd ever want to do, but
it is super useful for firmware debugging.
Hidden behind CAP_SYS_ADMIN and a default=n kconfig option, to prevent
it from being used on accident.
Signed-off-by: Ro
The fault recovery code tries to sync fences on all possible rings
instead of only the rings that actually exist which will fault the
kernel when the number of rings are less than the maximum amount.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
1 file changed, 1 inserti
Hi HL,
On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote:
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
>
> Signed-off-by: Lin Huang
> ---
> Changes in v2:
> - Change regulator property name to meet the panel datasheet
> Changes in v3:
> - this patch only refact
Hi, Christian,
While this has probably already been committed, and looks like a nice
cleanup there are two things below I think needs fixing.
On 11/15/2017 01:31 PM, Christian König wrote:
There is no guarantee that the next entry on the ddelete list stays on
the list when we drop the locks.
This looks okay to me. Although we should change eaction->tv_* type
to 64-bit as well.
I'll roll this in to our next pull request.
thanks,
Sinclair
On Mon, Nov 27, 2017 at 12:16:19PM +0100, Arnd Bergmann wrote:
> DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
> DRM_EVENT_VBLANK
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 367a3d2bdc27fd1d23be9ea75cec34b52297184d
commit: c1888183e1764d55d51ae051bd8651e634febe4d [374/701] ASoC: AMD: enable
ACP3x drivers build
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (De
On Wed, Dec 13, 2017 at 08:47:45PM +0100, Max Staudt wrote:
> Framebuffers with deferred I/O need to be flushed to the screen
> explicitly, since we use neither the mmap nor the file I/O abstractions
> that handle this for userspace FB clients.
>
> Example: xenfb
>
> Some framebuffer drivers impl
Hi Woody,
On Wed, Nov 22, 2017 at 04:05:50PM -0500, Woody Suwalski wrote:
> The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
> It is caused by a mismatch between the result of vmw_enable_vblank() and
> what the drm_atomic_helper expects:
> /...
> ret = drm_crtc_vblank_get(crtc
On Wed, Dec 13, 2017 at 02:35:16PM +0100, Daniel Vetter wrote:
> On Wed, Dec 13, 2017 at 01:05:49PM +, Chris Wilson wrote:
> > Quoting Daniel Vetter (2017-12-13 12:49:36)
> > > diff --git a/drivers/gpu/drm/drm_mode_config.c
> > > b/drivers/gpu/drm/drm_mode_config.c
> > > index 6ffe952142e6..76
1 - 100 of 117 matches
Mail list logo
