Hi
On Fri, Oct 13, 2023 at 5:41 AM Daniel Vetter wrote:
> > I mean we're not talking about scientific computing, or code
> > compilation, or seti@home. We're talking about nearly the equivalent
> > of `while (1) __asm__ ("nop");`
>
> I don't think anyone said this shouldn't be fixed or improved.
Hi,
On Mon, Oct 09, 2023 at 02:36:17PM +0200, Christian König wrote:
> > > > To be clear, my take is, if driver code is running in process context
> > > > and needs to wait for periods of time on the order of or in excess of
> > > > a typical process time slice it should be sleeping during the wai
Hi,
On Fri, Oct 6, 2023 at 3:12 AM Christian König wrote:
> When the operation busy waits then that *should* get accounted to the
> CPU time of the current process. When the operation sleeps and waits for
> some interrupt for example it should not get accounted.
> What you suggest is to put the p
Hi,
On Thu, Oct 5, 2023 at 5:57 AM Daniel Vetter wrote:
> So imo the trouble with this is that we suddenly start to make
> realtime/cpu usage guarantees in the atomic ioctl. That's a _huge_ uapi
> change, because even limited to the case of !ALLOW_MODESET we do best
> effort guarantees at best.
S
Hi,
On Wed, Oct 4, 2023 at 1:28 PM Ville Syrjälä
wrote:
> No one really seemed all that interested in it. I'd still like to get
> it in, if for no other reason than to make things operate more uniformly.
> Though there are lots of legacy codepaths left that still hold the locks
> over the whole c
hI,
On Thu, Sep 28, 2023 at 11:05 AM Ville Syrjälä
wrote:
> Here's my earlier take on this:
> https://patchwork.freedesktop.org/series/108668/
Nice. Was there push back? Why didn't it go in?
> execpt I went further and moved the flush past the unlock in the end.
Is that necessary? I was wonde
Hi,
On Thu, Sep 28, 2023 at 9:24 AM Christian König
wrote:
> If you see a large delay in the dpms off case then we probably have a driver
> bug somewhere.
This is something we both agree on, I think.
>> I'm getting the idea that you think there is some big bucket of kernel
>> syscalls that blo
hi,
On Thu, Sep 28, 2023 at 5:43 AM Michel Dänzer
wrote:
> >>> When it's really not desirable to account the CPU overhead to the
> >>> process initiating it then you probably rather want to use an non
> >>> blocking commit plus a dma_fence to wait for the work to end from
> >>> userspace.
> >> W
Hi,
On Thu, Sep 28, 2023 at 2:56 AM Christian König
wrote:
> > To say the "whole point" is about CPU overhead accounting sounds
> > rather absurd to me. Is that really what you meant?
>
> Yes, absolutely. See the functionality you try to implement already exists.
You say lower in this same messa
Hi,
On Wed, Sep 27, 2023 at 4:05 AM Christian König
wrote:
> I'm not an expert for that stuff, but as far as I know the whole purpose
> of the blocking functionality is to make sure that the CPU overhead
> caused by the commit is accounted to the right process.
I'm not an expert either, but that'
From: Ray Strode
A drm atomic commit can be quite slow on some hardware. It can lead
to a lengthy queue of commands that need to get processed and waited
on before control can go back to user space.
If user space is a real-time thread, that delay can have severe
consequences, leading to the
Hi,
On Wed, Dec 20, 2017 at 11:44 AM Max Staudt wrote:
> It'd be nice to see this bug fixed, as it happens only occasionally (as is
> the nature of a
> race condition), and was thus really hard to debug. I'm sure it can drive
> people insane,
> as they try to find out whether they've disabled C
Hi,
> Actually, I don't want that :)
>
> This was a design decision that I've made to keep the code small and simple
> to audit.
> As it is, the simple bootsplash code will make 99% of people happy.
You think only 1% of linux users have more than one monitor or a 4k screen?
> I've made this deci
Hi,
> The problem that I am stumbling upon is different:
> - the system starts with an FB driver
> - after the ShowDelay time, Plymouth opens /dev/fb0
> - the system finally loads the DRM driver, which tries to kick the previous
> FB driver
> - loading the DRM driver fails because Plymouth st
Hi,
On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote:
> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
> functional extension of that. It just happens that fbcon sits on top of FB,
> so I
> work with what I get.
>
> And the console in turn happens to work on all
Hi,
> For example, having a userspace splash that starts as early as it can
> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
> reserving the entirety of video RAM, and thus fail loading. This cannot be
> fixed.
well the fix there is to use drm devices... like this:
https://cgit
From: Ray Strode
This series includes a small leak fix and a fix for an initial invisible
cursor on wayland sessions.
Ray Strode (2):
drm/qxl: unref cursor bo when finished with it
drm/qxl: reapply cursor after resetting primary
drivers/gpu/drm/qxl/qxl_display.c | 63
From: Ray Strode
qxl_cursor_atomic_update allocs a bo for the cursor that
it never frees up at the end of the function.
This commit fixes that.
Signed-off-by: Ray Strode
---
drivers/gpu/drm/qxl/qxl_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu
From: Ray Strode
QXL associates mouse state with its primary plane.
Destroying a primary plane and putting a new one in place has the side
effect of destroying the cursor as well.
This commit changes the driver to reapply the cursor any time a new
primary is created. It achieves this by
Hi,
On Mon, Nov 27, 2017 at 4:07 PM Ray Strode wrote:
...
> This commit changes the driver to reapply the cursor any time a new
> primary is created. It achieves this by keeping a reference to the
> cursor bo on the qxl_crtc struct.
So i forgot this is on top of a small leak fix,
From: Ray Strode
QXL associates mouse state with its primary plane.
Destroying a primary plane and putting a new one in place has the side
effect of destroying the cursor as well.
This commit changes the driver to reapply the cursor any time a new
primary is created. It achieves this by
From: Ray Strode
The qxl driver currently destroys and recreates the
qxl "primary" any time the first crtc is set.
A side-effect of destroying the primary is mouse state
associated with the crtc is lost, which leads to
disappearing mouse cursors on wayland sessions.
This commit c
22 matches
Mail list logo