It's not obvious what the fields mean and how they should be used.
The most important detail is the link to drm_property.flags, which
describes how property types work.
Signed-off-by: Simon Ser
Cc: Pekka Paalanen
Cc: Daniel Vetter
Cc: Leandro Ribeiro
---
include/uapi/drm/drm_mode.h
When a property has the type DRM_MODE_PROP_BITMASK, the value field
stores a bitshift, not a bitmask, which can be surprising.
Signed-off-by: Simon Ser
Cc: Pekka Paalanen
Cc: Daniel Vetter
Cc: Leandro Ribeiro
---
include/drm/drm_property.h | 5 +
1 file changed, 5 insertions(+)
diff
We already have logging for ADDFB2. Add some logging for RMFB as
well.
This can be handy when trying to find out why a CRTC gets magically
disabled.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_framebuffer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu
We already have logging for ADDFB2. Add some logging for RMFB as
well.
This can be handy when trying to find out why a CRTC gets magically
disabled.
v2: make log message more explicit, add log messages to
drm_framebuffer_remove (Daniel)
Signed-off-by: Simon Ser
Cc: Daniel Vetter
---
drivers
Since there's no struct to attach the docs to, document the IOCTL
definition.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Leandro Ribeiro
---
include/uapi/drm/drm.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uap
On Wednesday, July 21st, 2021 at 13:39, Daniel Vetter wrote:
> I think it would be really good to link to
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#modeset-base-object-abstraction
>
> for all the property related ioctl. That entire class vs instance
> confusion is pretty common I
On Tuesday, July 27th, 2021 at 11:26, Daniel Vetter wrote:
> I think the least intrusive one is `Title Test`_ or so. There's also other
> places where we use :ref: but that's more cumbersome to read in plain
> text.
Yeah, tried it, doesn't work. The link doesn't appear.
It's not obvious what the fields mean and how they should be used.
The most important detail is the link to drm_property.flags, which
describes how property types work.
v2: document enum drm_mode_property_enum, add ref to "Modeset Base
Object Abstraction" (Daniel)
Signed-off-by: S
Pushed this one doc patch with Daniel's R-b on IRC.
On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen
wrote:
> Btw. can force-probe be triggered via sysfs as well and does it require
> root privs?
sysfs can force-probe like so:
echo detect | sudo tee /sys/class/drm/card0-DP-1/status
But this requires root, yes.
_
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
definitely be interested in using such as library. A C API with no
dependencies is pretty important from my point-of-view.
I'd prefer if C++ was not used at all (and could almost be baited into
doing the work if that were the c
On Wednesday, April 7th, 2021 at 3:51 PM, Ville Syrjälä
wrote:
> > +* To find out the list of formats that support modifiers, userspace
> > +* must use the plane IN_FORMATS blob property.
> > */
>
> Addfb2+modifiers predates the IN_FORMATS blob, so this doesn't
> match reality.
TBH
Ah, I haven't seen the second patch...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
wrote:
> Perhaps that should be the takeaway; try to minimize parsed data
> where the consumer needs to know whether it originated from DisplayID or
> EDID?
So an EDID/DisplayID abstraction layer?
It sounds like only an EDID and DisplayID ex
On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula
wrote:
> On Thu, 08 Apr 2021, Simon Ser cont...@emersion.fr wrote:
>
> > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula
> > jani.nik...@linux.intel.com wrote:
> >
> > > Perhaps that should be the take
On Tuesday, April 13th, 2021 at 11:49 AM, Daniel Vetter
wrote:
> + * Note that userspace can check the DRM_CAP_ADDFB2_MODIFIERS driver
Prepend an ampersand like so and a hyperlink will be rendered:
Note that userspace can check the &DRM_CAP_ADDFB2_MODIFIERS driver
_
Reviewed-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi all,
I'm working on a Wayland extension [1] that, among other things, allows
compositors to advertise the preferred device to be used by Wayland
clients.
In general, compositors will send a render node. However, in the case
of split render/display SoCs, things get a little bit complicated.
Th
Ping Daniel Vetter
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Leandro,
Any chance you could re-spin at least the first patch?
Thanks,
Simon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tuesday, April 20th, 2021 at 11:14 AM, Daniel Vetter wrote:
> Do we have an igt for this? Timing test should do the job I think,
> assuming we have at least one output which requires an edid read (so maybe
> skip the test if a forced probe takes less than 10ms or so).
Err, an igt that only re
Hi,
On Wednesday, April 21st, 2021 at 10:47 PM, Hans de Goede
wrote:
> There now is GNOME userspace code using the new properties:
> https://hackmd.io/@3v1n0/rkyIy3BOw
Thanks for working on this.
Can these patches be submitted as merge requests against the upstream
projects? It would be nice
On Thursday, April 22nd, 2021 at 10:54 AM, Hans de Goede
wrote:
> I guess Marco was waiting for the kernel bits too land before submitting
> these,
> but I agree that it would probably be good to have these submitted now, we
> can mark them as WIP to avoid them getting merged before the kernel
On Saturday, April 24th, 2021 at 3:57 PM, Melissa Wen
wrote:
> -- Real overlay planes, not just cursor.
Maybe we should mention "multiple overlay planes" as a good task?
Thanks,
Simon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https:
Thanks for the feedback! Replying to both Daniels below.
On Tuesday, April 20th, 2021 at 1:14 PM, Daniel Vetter
wrote:
> On Tue, Apr 20, 2021 at 12:18 PM Daniel Stone wrote:
>
> >> There are a few solutions:
> >>
> >> 1. Require compositors to discover the render device by trying to import
> >
On Monday, April 26th, 2021 at 9:36 AM, Pekka Paalanen
wrote:
> > > This should probably explain what the bits in the mask correspond to.
> > > As in, which CRTC does bit 0 refer to, and so on.
> >
> > What about:
> >
> > "possible_crtcs: Bitmask of CRTC's compatible with the plane. CRTC's are
>
Reviewed-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tuesday, April 27th, 2021 at 7:31 PM, Lucas Stach
wrote:
> > Ok. So that would only make the following use cases broken for now:
> >
> > - amd render -> external gpu
> > - amd video encode -> network device
>
> FWIW, "only" breaking amd render -> external gpu will make us pretty
> unhappy
I
On Tuesday, April 27th, 2021 at 8:01 PM, Alex Deucher
wrote:
> It's an upcoming requirement for windows[1], so you are likely to
> start seeing this across all GPU vendors that support windows. I
> think the timing depends on how quickly the legacy hardware support
> sticks around for each vendo
> A solution to make this configuration generic and exposed by the kernel
> would standardise this across Linux
Having a KMS property for this makes sense to me.
Chatting with Jani on IRC, it doesn't seem like there's any EDID or
DisplayID block for this.
Note, Android exposes a data structure [
On Wednesday, April 28th, 2021 at 9:44 AM, Pekka Paalanen
wrote:
> I'm kind of worried whether you can design a description structure that
> would be good for a long time. That list already looks quite
> complicated. Add also watch-like devices with circular displays.
>
> Would the kernel itself
On Wednesday, April 28th, 2021 at 2:21 PM, Daniel Vetter
wrote:
> Yeah I think we have pretty clear consensus on that goal, just no one yet
> volunteered to get going with the winsys/wayland work to plumb drm_syncobj
> through, and the kernel/mesa work to make that optionally a userspace
> fence
Let the user know what went wrong in drm_gem_fb_init_with_funcs
failure paths.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Andrzej Pietrasiewicz
---
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion
Let the user know what went wrong in drm_gem_fb_init_with_funcs
failure paths.
v2: use proper format specifier for size_t (kernel test robot)
Signed-off-by: Simon Ser
Reviewed-by: Michel Dänzer
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc: Noralf Trønnes
Cc: Andrzej Pietrasiewicz
---
drivers/gpu
On Wednesday, August 11th, 2021 at 11:43, Daniel Vetter wrote:
> For wayland this is still in the works, so might be good if you check
> there that your use-case is properly supported. Protocol MR is here:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/67
The clien
On Wednesday, August 11th, 2021 at 12:19, John Cox wrote:
> That MR seems to be done so is probably an inappropriate
> place to ask - where would you recommend as an appropriate forum?
For Wayland related questions, you can ask on IRC or on the
wayland-devel mailing list.
Reviewed-by: Simon Ser
Do you need me to push this?
On Wednesday, August 11th, 2021 at 13:40, John Cox wrote:
> Raspberry Pi displaying video with subtitles or other controls. I was
> thinking of the fullscreen case but if zero copy video can be made to
> work to the main desktop then that would even better.
>
> If displaying 4k video the Pi does
Pushed to drm-misc-next, thanks!
Maybe ask one of the maintainers/owners listed in GitLab [1]?
Please make sure you're familiar with the contributing guidelines [2].
[1]:
https://gitlab.freedesktop.org/mesa/drm/-/project_members?sort=access_level_desc
[2]: https://gitlab.freedesktop.org/mesa/drm/-/blob/main/CONTRIBUTING.rst
On Friday, March 19th, 2021 at 8:06 PM, Lucas Stach
wrote:
> +/*
> + * Vivante TS (tile-status) buffer modifiers. They can be combined with all
> of
> + * the color buffer tiling modifiers defined above. When TS is present it's a
> + * separate buffer containing the clear/compression status of
Can we instead have a macro/function to get the vendor? This would be
useful elsewhere as well, see drmGetFormatModifierVendor in a recent-ish
libdrm patch [1].
[1]:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/108/diffs#91ecb12b27c7154b26013bb95e17a5cc24ea443e_947_947
___
Side note: I feel like we could have better lines of communication
between kernel devs and user-space devs. The new uAPI requirements seem
to be a high barrier to entry for kernel devs. However sometimes
user-space devs might be interested in helping out with the user-space
part…
Maybe it would be
>From a user-space point-of-view, this looks super useful! The uAPI sounds
good to me.
Acked-by: Simon Ser
Would be nice to have some short docs as well. Here's an example of a
patch adding some docs for an ioctl [1], if you aren't familiar with
that. I think just some basic stuff
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Simon Ser
I'll push this shortly to drm-misc-next.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
LGTM, thanks!
Reviewed-by: Simon Ser
Let me know if you need me to push this to drm-misc-next.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Saturday, March 27th, 2021 at 12:22 PM, Paul Cercueil
wrote:
> The ingenic-drm driver has two mutually exclusive primary planes
> already; so the fact that a CRTC must have one and only one primary
> plane is an invalid assumption.
Why does this driver expose two primary planes, if it only h
On Monday, March 29th, 2021 at 4:07 PM, Maxime Ripard wrote:
> Since it looks like you have two mutually exclusive planes, just expose
> one and be done with it?
You can expose the other as an overlay. Clever user-space will be able
to figure out that the more advanced plane can be used if the p
On Monday, March 29th, 2021 at 5:32 PM, Paul Cercueil
wrote:
> Making the second plane an overlay would break the ABI, which is never
> something I'm happy to do; but I'd prefer to do it now than later.
Yeah, I wonder if some user-space depends on this behavior somehow?
> I still have concerns
On Monday, March 29th, 2021 at 5:39 PM, Paul Cercueil
wrote:
> Ok, I read that as "all drivers should provide AT LEAST one primary
> plane per CRTC", and not as "all drivers should provide ONE AND ONLY
> ONE primary plane per CRTC". My bad.
Yeah, it's a little complicated to document, because i
> It should have been an OVERLAY from the beginning. The documentation
> stipulates that there should be an unique PRIMARY plane per CRTC.
Thanks for the quick patch! One comment below…
> Fixes: fc1acf317b01 ("drm/ingenic: Add support for the IPU")
> Cc: # 5.8+
> Signed-off-by: Paul Cercueil
>
wise it would only match the f1
> plane.
Oh okay, I thought f0 was one of the primary planes, but it's not.
Thanks for the explanation.
For the user-space visible change:
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
connector
query.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_connector.c | 11 ---
include/uapi/drm/drm_mode.h | 7 ---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_c
ototype was for drmm_crtc_alloc_with_planes()
> instead
>
> Signed-off-by: Mauro Carvalho Chehab
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thursday, January 14th, 2021 at 9:06 AM, Simon Ser
wrote:
> On Thursday, January 14th, 2021 at 9:04 AM, Mauro Carvalho Chehab
> wrote:
>
> > A function has a different name between their prototype
> > and its kernel-doc markup:
> >
> > ../include/drm/dr
On Tuesday, December 22nd, 2020 at 2:59 PM, Daniel Vetter
wrote:
> > + * type:
> > + * Immutable property describing the type of the plane.
> > + *
> > + * For user-space which has enabled the
> > &DRM_CLIENT_CAP_UNIVERSAL_PLANES
>
> s/UNIVERSAL_PLANES/ATOMIC/ here?
>
> With just univer
these docs are for driver developers,
not userspace developers, so internal kernel APIs are mentionned.
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
include/drm/drm_plane.h | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a
IC instead of CAP_UNIVERSAL_PLANES when referring to
atomic test-only commits (Daniel)
- Add newlines at end of sections (Daniel)
Signed-off-by: Simon Ser
Reviewed-by: Daniel Vetter
Cc: Pekka Paalanen
---
drivers/gpu/drm/drm_plane.c | 58 ++---
1 file c
s: Add format mod prop to
> base/ovly/nvdisp")
> Cc: James Jones
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Cc: # v5.8+
> Signed-off-by: Lyude Paul
Together with [1], this patch allows me to run unpatched modifier-aware
user-space successfully, without a c
On Tuesday, January 19th, 2021 at 2:54 AM, Lyude Paul wrote:
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drive
> Cc: Martin Peres
> Cc: Jeremy Cline
> Cc: Simon Ser
> Signed-off-by: Lyude Paul
Code LGTM:
Reviewed-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thursday, January 21st, 2021 at 9:27 AM, Daniel Vetter
wrote:
> > I would not call it USB. I could imagine that at some point a generic
> > USB protocol could serve simple displays (i.e. in the sense of USB HID
> > or data or imaging). (Maybe Thunderbold already counts.) Anyway, USB
> > shoul
On Thursday, January 21st, 2021 at 10:59 AM, Thomas Zimmermann
wrote:
> Well, I'd strongly ask to not call it "generic", because it isn't. We
> have other USB drivers and anyone can make a USB display with these
> protocols as well. That doesn't make them generic. A USB-standardized
> protocol w
On Sunday, January 24th, 2021 at 5:40 AM, Mario Kleiner
wrote:
> According to the CTA 861.G spec, HDMI_STATIC_METADATA_TYPE1 is
> not 1, but zero, so fix this enum.
>
> While this doesn't cause problems in the kernel yet, as the
> constant isn't actively used by drivers yet, it did create
> conf
On Sunday, January 24th, 2021 at 9:10 PM, Mario Kleiner
wrote:
> But it still needs to be fixed if we want working HDR. I thought
> libdrm copies the definitions from the kernel periodically, so the
> fix should propagate?
There will always be user-space that sends 1 instead of 0. This
shouldn'
> This is not an uapi defintion anyway so fixing should be fine.
Oh, my bad, I thought this was in drm_mode.h, but it's not. Then yeah
should be completely fine to fix it.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedeskt
‐‐‐ Original Message ‐‐‐
On Monday, January 25th, 2021 at 5:00 PM, Mario Kleiner
wrote:
> On Mon, Jan 25, 2021 at 1:14 PM Simon Ser wrote:
>
> > > This is not an uapi defintion anyway so fixing should be fine.
> >
> > Oh, my bad, I thought this was in drm
On Monday, January 25th, 2021 at 5:08 PM, Mario Kleiner
wrote:
> In some way it would even be nice to have all that info exposed in
> parsed form as a connector property or such, so all clients can use
> the same parsed data instead of reinventing the wheel.
So far the policy has more or less b
On Thursday, January 28th, 2021 at 1:03 PM, Sumit Semwal
wrote:
> Since he didn't comment over Hridya's last clarification about the
> tracepoints to track total GPU memory allocations being orthogonal to
> this series, I assumed he agreed with it.
IIRC he's away this week. (I don't remember wh
On Friday, January 29th, 2021 at 3:13 PM, Pekka Paalanen
wrote:
> > Re-importing it adds quite a huge CPU overhead to both userspace as well
> > as the kernel.
>
> Perhaps, but so far it seems no-one has noticed the overhead, with Mesa
> at least.
>
> I happily stand corrected.
Note, all of thi
On Thursday, December 10th, 2020 at 10:12 AM, James Park
wrote:
> +#ifndef _DRM_BASIC_TYPES_H_
> +#define _DRM_BASIC_TYPES_H_
Nit: the rest of the kernel doesn't use an underscore prefix for these
defines. Note that anything starting with an underscore followed by an
upper-case letter is a rese
On Tuesday, February 2nd, 2021 at 9:51 AM, Simon Ser
wrote:
> On Thursday, December 10th, 2020 at 10:12 AM, James Park
> jpar...@lagfreegames.com wrote:
>
> > +#ifndef _DRM_BASIC_TYPES_H
> > +#define _DRM_BASIC_TYPES_H
>
> Nit: the rest of the kernel doesn't us
On Tuesday, February 2nd, 2021 at 11:48 PM, Emil Velikov
wrote:
> P.S. Please try to avoid top-posting and HTML emails in public discussions.
(James: as a side note, here is a guide to configure your e-mail client
to use plain-text: https://useplaintext.email/)
_
On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
wrote:
> As summed in the commit message the burden is only applicable when all
> of the following are set:
> - non-linux
> - force DRM_FOURCC_STANDALONE
> - c99 -pedantic
>
> Even then, we're talking about a compilation warning. So ye
On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
emil.l.veli...@gmail.com wrote:
> As summed in the commit message the burden is only applicable when all
> of the following are set:
> - non-linux
> - force DRM_FOURCC_STANDALONE
> - c99 -pedantic
Oh, and FWIW, this is not a theoretica
On Wednesday, February 3rd, 2021 at 11:08 AM, Emil Velikov
wrote:
> On Wed, 3 Feb 2021 at 09:27, Simon Ser wrote:
> >
> > On Wednesday, February 3rd, 2021 at 1:56 AM, Emil Velikov
> > emil.l.veli...@gmail.com wrote:
> >
> > > As summed in the commit messag
On Wednesday, February 3rd, 2021 at 12:03 PM, Emil Velikov
wrote:
> No issue then, great. Let's merge this trivial solution and move on to
> other things.
Just because one compositor isn't affected isn't an excuse for the
kernel to force its users to use a specific C standard.
_
On Wednesday, February 3rd, 2021 at 3:13 PM, Emil Velikov
wrote:
> As said before, there are multiple ways to handle this without
> introducing yet another UAPI header. I don't see why you're dismissing
> all of them, can you elaborate?
Because I hate it when I have to adjust my compiler flags
On Thursday, February 4th, 2021 at 10:15 PM, James Park
wrote:
> No, I haven't pushed anything with DRM_BASIC_TYPES_DEFINED yet. I was
> just illustrating since DRM_BASIC_TYPES_H would not be a great
> choice for a name in this case.
This approach looks fine to me too. I'd R-b it.
Thanks for y
Please keep the commit message short. You probbly want to send this patch
to amd-...@lists.freedesktop.org instead of dri-devel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Acked-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wednesday, February 10th, 2021 at 2:16 PM, Daniel Vetter
wrote:
> On Tue, Feb 09, 2021 at 04:14:01PM -0800, Manasi Navare wrote:
>
> > These additional checks added to avoid EBUSY give unnecessary WARN_ON
> > in case of big joiner used in i915 in which case even if the modeset
> > is requeste
On Wednesday, February 10th, 2021 at 10:04 PM, Mario Kleiner
wrote:
> Ping!
I now understand the problem better.
Reviewed-by: Simon Ser
I'll push to drm-misc-next in a few days if no-one complains. Ping me
again if I forget.
___
dri-devel
On Wednesday, February 10th, 2021 at 11:02 PM, Mario Kleiner
wrote:
> I'll prepare patches with the same fix for libdrm and igt as well soon.
Please don't submit patches for drm_fourcc.h to downstream if they vendor the
whole file. Instead, update it from the kernel once your patch is merged to
On Friday, February 12th, 2021 at 1:57 PM, Emil Velikov
wrote:
> On Fri, 5 Feb 2021 at 22:01, Chris Wilson wrote:
> >
> > Userspace has discovered the functionality offered by SYS_kcmp and has
> > started to depend upon it. In particular, Mesa uses SYS_kcmp for
> > os_same_file_description() in
On Monday, February 15th, 2021 at 9:58 AM, Christian König
wrote:
> we are currently working an Freesync and direct scan out from system
> memory on AMD APUs in A+A laptops.
>
> On problem we stumbled over is that our display hardware needs to scan
> out from uncached system memory and we curren
On Tuesday, February 16th, 2021 at 1:39 AM, Deepak Rawat
wrote:
> +static int hyperv_conn_init(struct hyperv_drm_device *hv)
> +{
> + drm_connector_helper_add(&hv->connector,
> &hyperv_connector_helper_funcs);
> + return drm_connector_init(&hv->dev, &hv->connector,
> +
On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
wrote:
> >> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9804:38:
> >> warning: variable 'i' is uninitialized when used here
> >> [-Wuninitialized]
>timing = &edid->detailed_timings[i];
>
On Tuesday, February 23rd, 2021 at 12:44 AM, Nathan Chancellor
wrote:
> On Mon, Feb 22, 2021 at 11:05:17PM +0000, Simon Ser wrote:
> > On Monday, February 22nd, 2021 at 8:25 PM, Souptick Joarder
> > wrote:
> >
> > > >> drivers/gpu/drm/amd/amdgpu/../d
On Tuesday, February 23rd, 2021 at 6:42 PM, Alex Deucher
wrote:
> yeah, fdo ran out of disk space so I moved to gitlab:
>
> https://gitlab.freedesktop.org/agd5f/linux/-/commits/drm-next
Ah, thanks for the info, my bad!
___
dri-devel mailing list
dri-d
Pushed, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Good catch!
Reviewed-by: Simon Ser
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tuesday, March 2nd, 2021 at 7:47 PM, Lionel Landwerlin
wrote:
> Thanks Simon. Do you have the rights to push this patch?
Ah, since you're asking about this, it probably means you don't have the
rights. I'll push the patch now to drm-misc-next.
___
Document all of the DRM_CAP_* defines.
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 100 +++--
1 file changed, 96 insertions(+), 4 deletions(-)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index
On Friday, March 5th, 2021 at 9:28 AM, Pekka Paalanen
wrote:
> > +/**
> > + * DRM_CAP_DUMB_PREFERRED_DEPTH
> > + *
> > + * The preferred depth (in bits) for dumb buffers.
>
> this is literally depth, not bits per pixel, right?
"Depth" is pretty ambiguous [1]. Maybe we should be more explicit he
R-b me. Pushed, thanks!
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Monday, March 8th, 2021 at 9:20 AM, Pekka Paalanen
wrote:
> > > > +/**
> > > > + * DRM_CAP_CRTC_IN_VBLANK_EVENT
> > > > + *
> > > > + * If set to 1, the kernel supports reporting the CRTC ID in
> > > > + * &drm_event_vblank.crtc_id.
> > >
> > > Does this not apply also to the pageflip / atomi
CLOCK_MONOTONIC
- Make it clear DRM_CAP_CRTC_IN_VBLANK_EVENT applies to both DRM_EVENT_VBLANK
and DRM_EVENT_FLIP_COMPLETE
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
---
include/uapi/drm/drm.h | 112 +++--
1 file changed, 108 insertions(+), 4
On Monday, May 3rd, 2021 at 4:20 PM, Rodrigo Siqueira
wrote:
> > diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > index 109d11fb4cd4..aeb808a0ba54 100644
> > --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> > +++ b/drivers/gpu/
1 - 100 of 971 matches
Mail list logo
