;> I can't immediately think of something better, though.
>
> Yeah, I was wondering about that as well. Especially since I wanted to add
> some more flags in the future when for example a bandwidth quota how much
> memory can be moved in/out is exceeded.
>
> Something like
k.
>>>>>
>>>>> The driver exposing those details would be quite useful for userspace
>>>>> though, so that it can delay committing updates to late, but not too
>>>>> late. Setting a deadline to be the vblank seems easy eno
his should be >> or no shift instead of <<, shouldn't it? Multiplying a value
in bytes by the page size doesn't make sense.
I didn't check the rest of the patch in detail, but it's easy introduce subtle
regressions with this kind of change. It'll require a lot of review & testing
scrutiny.
--
Earthling Michel Dänzer| https://redhat.com
Libre software enthusiast | Mesa and Xwayland developer
On 2021-09-30 14:27, Matthew Auld wrote:
> On 30/09/2021 11:04, Michel Dänzer wrote:
>> On 2021-09-29 13:54, Thomas Hellström wrote:
>>> On Mon, 2021-09-27 at 12:41 +0100, Matthew Auld wrote:
>>>> This should let us do an accelerated copy directly to the shmem page
ace while evicted, and this will appear to user-space like the
> WC-mapped object suddenly became WB-mapped. But it appears like mesa
> doesn't care about this as long as the mappings are fully coherent.
FWIW, the Mesa radeonsi driver avoids surprises due to this (e.g
issue and mesa was using
SYS_kcmp to compare device node fds.
A far shorter and more portable solution is possible, so let me
prepare a Mesa patch.
Make sure to read my comments on
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6881 first. :)
--
Earthling Michel Dänzer
On 2021-02-08 2:34 p.m., Daniel Vetter wrote:
On Mon, Feb 8, 2021 at 12:49 PM Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the
On 2021-02-08 12:49 p.m., Michel Dänzer wrote:
On 2021-02-05 9:53 p.m., Daniel Vetter wrote:
On Fri, Feb 5, 2021 at 7:37 PM Kees Cook wrote:
On Fri, Feb 05, 2021 at 04:37:52PM +, Chris Wilson wrote:
Userspace has discovered the functionality offered by SYS_kcmp and has
started to depend
select if CONFIG_DRM is
unfortunately needed I think.
Per above, not sure this is really true.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
ether it was an async flip or not.
As for the timestamp in the event, I'm not sure what the expectations
are for async flips, but I suspect it may not really matter. E.g. the
timestamp calculated to correspond to the end of the previous vertical
blank period might be fine.
--
E
gt; using async flips.
This definitely looks wrong. The counter value returned by the
get_vblank_counter hook is supposed to increment when a vertical blank
period occurs; page flips are not supposed to affect this in any way.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
ot really surprising? :)
> - _and_ you're using the legacy page_flip path, atomic flip doesn't
> support it
Simon Ser has VRR working with sway using the atomic KMS API.
> - _and_ the PAGE_FLIP_ASYNC flag is set.
AFAIK it works both without and with PAGE_FLIP_ASYNC. (Async just m
ered jobs don't exist at all in the pipeline, so they can't
be triggered by any means. :)
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
_
On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> pre-merge CI.
Thanks for the suggestion! I implemented something like this for Mesa:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432
--
Earth
be only triggered manually instead of automatically on every push.
That would again break Marge Bot.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
which is somewhat more robust:
>> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2569
>
> I'm not sure it's more robust, but yeah that a useful tool too.
>
> The reason I'm skeptical about the robustness is that we'll miss
> testing if this misses
an one which is already caught earlier.
--
Earthling Michel Dänzer | https://redhat.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
to unsigned long, which keeps the generated code the same
>>>> (verified with clang-11 on x86_64 and GCC 9.2.0 on x86 and x86_64) and
>>>> the warning is silenced so we can catch more potential issues in the
>>>> future.
>>>>
>>>>
On 2020-02-12 6:07 p.m., Nathan Chancellor wrote:
> On Wed, Feb 12, 2020 at 09:52:52AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
>>> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
>>>> On 2020-02-11 7:13 a.m., Na
On 2020-02-11 9:39 p.m., Nathan Chancellor wrote:
> On Tue, Feb 11, 2020 at 10:41:48AM +0100, Michel Dänzer wrote:
>> On 2020-02-11 7:13 a.m., Nathan Chancellor wrote:
>>> A recent commit in clang added -Wtautological-compare to -Wall, which is
>>> enabled for i915 so w
x86_64 but that check is relevant for
> 32-bit x86 so we cannot remove it.
That's suprising. AFAICT N_RELOC(ULONG_MAX) works out to the same value
in both cases, and remain is a 32-bit value in both cases. How can it be
larger than N_RELOC(ULONG_MAX) on 32-bit (but not on 64-bit)?
--
Earth
>
> Everyone else will stay as broken with CONFIG_DRM_DP_AUX_CHARDEV. The
> next patch will improve the kerneldoc and add a todo entry for this.
>
> Fixes: 4f5368b5541a ("drm/kms: Catch mode_object lifetime errors")
> Cc: Sean Paul
> Cc: Maarten Lankhorst
> Repor
gt; Would your GPU_MAPPED above work for TT? I think we'll also need
> STOLEN, I'm even hearing noises that there's going to be stolen for
> discrete vram for us ...
Could i915 use DRM_MEM_PRIV for stolen? Or is there other hardware with
witch/case to make code obvious.
>
> Analysis from Michel Dänzer:
>
> The waiting condition rely on all relevant places where vblank_count
> is modified calls wake_up(&vblank->queue).
>
> drm_handle_vblank():
> - Calls wake_up(&vblank->queue)
>
> drm_v
d expand our variable size reservation_list to take advantage
> of that extra space.
>
> Signed-off-by: Chris Wilson
> Cc: Christian König
> Cc: Michel Dänzer
> ---
> drivers/dma-buf/reservation.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> di
e isn't feasible, but I haven't seen any evidence
supporting that.
Since this change is essentially a workaround for broken userspace which
can never have worked, and has the potential of subverting the ongoing
transition from using primary nodes to render nodes in userspace code,
there needs
On 2019-06-27 9:35 a.m., Pekka Paalanen wrote:
>
> Are connector names in xrandr still using type_id in their names?
Yes, they are.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X dev
> will change.
>
> To make this perfectly clear, also add a comment to DRM_UNLOCKED.
>
> Cc: Emil Velikov
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 139 ++--
> include/drm/drm_ioctl.h | 3 +
> 2 files changed, 72 ins
h
RADEON_INFO_ACCEL_WORKING, but later RADEON_INFO_ACCEL_WORKING2 had to
be added, because the former claimed acceleration was "working" in cases
where it really wasn't... That kind of thing could become ugly in the
long run if other Xorg driver start using atomic, and they'll ine
On 2019-03-13 5:16 p.m., Kazlauskas, Nicholas wrote:
> On 3/13/19 11:54 AM, Christian König wrote:
>> Am 13.03.19 um 16:38 schrieb Michel Dänzer:
>>> On 2019-03-13 2:37 p.m., Christian König wrote:
>>>> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>>>>
On 2019-03-13 2:37 p.m., Christian König wrote:
> Am 13.03.19 um 14:31 schrieb Ville Syrjälä:
>> On Wed, Mar 13, 2019 at 10:35:08AM +0100, Michel Dänzer wrote:
>>> On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>>>>
>>>> Den 12.03.2019 17.17, skrev Ville
On 2019-03-12 6:15 p.m., Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>>> This adds support for outputting kerne
all.
There would need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
l driver is allowing DRI2/Present page flipping
while there's an SW cursor? That cannot work correctly, as the SW cursor
image is missing in the newly flipped pixmap, and the SW cursor code
will restore stale background contents to it when the cursor has to be
drawn again.
--
Earthling Miche
se run
git rm tests/gem_ctx_bad_exec
and re-send the patch.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.
(ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Suggested-by: Michel Dänzer
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/
gt;> s/int/u32/ in drm_core_check_feature() args
>>>
>>> Cc: Chris Wilson
>>> Signed-off-by: Ville Syrjälä
>>
>> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
>> case for this. Exactly same problem as we have here. Would be
On 2018-03-13 04:20 PM, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> To make it possible for the core to check the fb pixel format and
&g
On 2018-03-13 04:12 PM, Ville Syrjälä wrote:
> On Tue, Mar 13, 2018 at 03:38:38PM +0100, Michel Dänzer wrote:
>> On 2018-03-13 03:28 PM, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> To make it possible for the core to check the fb pixel format and
&g
b_modifier() hook for that purpose and convert i915
> and vc4 to make use if it. All other drivers seem to currently
> assume linear when the request does not specify anything else,
> [...]
That's not true at least for the amdgpu and radeon drivers. The tiling
mode is communicated via
gt;>>
>>> Thanks,
>>>
>>> Lukas
>>
>> I would say fixes, it doesn't look particularly scary. :)
>
> Agreed. If it's good enough for stable, it's good enough for -fixes!
It's no
.) It may be premature to start exposing hooks into it.
Sounds like it may not be too late to abandon the separate i915
scheduler in favour of the common one used by amdgpu and etnaviv?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast
On 07/11/17 11:50 AM, Ville Syrjälä wrote:
> On Tue, Nov 07, 2017 at 10:47:00AM +0100, Michel Dänzer wrote:
>> On 07/11/17 07:26 AM, Dhinakaran Pandiyan wrote:
>>> Some HW vblank counters reset due to power management events, which messes
>>> up the vblank counting
reset to 0 might happen? If there is, maybe it could be solved by
calling drm_crtc_vblank_off() before it might happen and
drm_crtc_vblank_on() after it might have happened.
Otherwise, might it be better not to use the HW counter at all when it's
known not to be reliable?
--
Earthling Michel Dän
On 13/07/17 05:27 PM, Michel Dänzer wrote:
> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Signed-off-by: Michel Dänzer
>> ---
>>
>> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
>> drivers, right?
>
do that while anyone has the
> fd still open, so lastclose is guaranteeed to run.
> - Forcefully unbinding the driver through sysfs. Not any better, since
> the can_switch stuff checks for the open count, and so will delay the
> delayed switch no matter what.
Are you
On 14/07/17 11:24 AM, Ilia Mirkin wrote:
> On Thu, Jul 13, 2017 at 10:14 PM, Michel Dänzer wrote:
>> On 13/07/17 09:31 PM, Ilia Mirkin wrote:
>>> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer wrote:
>>>> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>>>>
On 13/07/17 09:31 PM, Ilia Mirkin wrote:
> On Thu, Jul 13, 2017 at 4:27 AM, Michel Dänzer wrote:
>> On 18/04/17 07:07 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> Signed-off-by: Michel Dänzer
>>> ---
>>>
>>> Chri
On 18/04/17 07:07 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
>
> Chris / Ilia / Ben, this should be manageable for the intel/nouveau
> drivers, right?
Any feedback, guys?
I want to push the xserver change soon-ish. I could pr
On 21/06/17 05:14 PM, Daniel Vetter wrote:
> On Wed, Jun 21, 2017 at 04:59:31PM +0900, Michel Dänzer wrote:
>> On 21/06/17 04:38 PM, Daniel Vetter wrote:
>>> On Tue, Jun 20, 2017 at 09:25:25PM +0200, Peter Rosin wrote:
>>>> This makes the redundant fb helpers .load_
ther bug,
> but might be relevant for your use-case. Just try to run both an fbdev
> application and some kms-native thing, and then SIGKILL the native kms
> app.
>
> But since pre-existing not really required, and probably too much effort.
I suspect somet
Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Reported-by: Tommi Rantala
> Cc: Tommi Rantala
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 5 +++--
> 1 file changed,
rm: Roll out acquire context for the page_flip ioctl")
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-de...@lists.freedesktop.org
> Reported-by: Tommi Rantala
> Cc: Tommi Rantala
> Cc: Michel Dänzer
>
From: Michel Dänzer
This allows making the master screen's pixmap_dirty_list entries
explicitly reflect that we're now tracking the root window instead of
the screen pixmap, in order to allow Present page flipping on master
outputs while there are active slave output
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Chris / Ilia / Ben, this should be manageable for the intel/nouveau
drivers, right?
src/amdgpu_drv.h | 26 ++
src/amdgpu_kms.c | 18 +-
src/drmmode_display.c | 8 ++--
3 files changed
gt; +interacting with community members on mailing lists, IRC, or bug
> +trackers. The community represents the project as a whole, and abusive
> +or bullying behaviour is not tolerated by the project.
>
Acked-by: Michel Dänzer
--
Earthling Michel Dänzer |
ation when someone would call a cursor_set ioctl
> in parallell for two crtcs at the same time and race writing the
> position registers?
> Note that the device has only a single global cursor.
> Admittedly the effects of a race would probably be smal
On 22/03/17 07:06 PM, Chris Wilson wrote:
> Move the repeated (a - b) <= (1 << 23) to its own function.
>
> v2: Catch the '1<<23' inside drm_handle_vblank() as well
>
> Signed-off-by: Chris Wilson
Reviewed-by: Michel Dänzer
--
Earthling Michel D
vblank_passed(drm_vblank_count(dev, pipe),
> + vblwait->request.sequence) ||
> !READ_ONCE(vblank->enabled));
> }
>
>
There's another instance in drm_handle_vblank_events.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
for driver maintainers, Eric for vc4 here.
>>
>> Eric was cc:d. I was just too lazy to add the cc:s to all the commit
>> messages, and so i just used --cc on the whole lot.
>
> Hm, he's not on the cc: list over here (on the mails, not in the patch
>
pu-pro stack, with
modifications which are probably unsuitable for -modesetting. There's
also still a feature gap to -modesetting, e.g. the latter doesn't
support TearFree yet, and there doesn't seem to be any interest to fix that.
So I'm afraid we can't get rid of those any
On 07/12/16 11:49 PM, Daniel Vetter wrote:
> vgem (and our igt tests using vgem) need this. I suspect etnaviv will
> fare similarly.
>
> v2. Make it build. Oops.
>
> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a
> non-KMS driver")
ch gets those two branches
> working again
>
> Sorry to be the bearer of bad news - I'm guessing this is PRIME related
It's not. You can choose between
https://patchwork.freedesktop.org/patch/125754/
or
https://patchwork.freedesktop.org/patch/125644/
On 08/09/16 02:23 AM, Imre Deak wrote:
> This fixes the error path for platforms that don't define the new
> page_flip_target() hook.
>
> Fixes: c229bfbbd04 ("drm: Add page_flip_target CRTC hook v2")
> Testcase: igt/kms_flip/basic-flip-vs-dpms
> CC: Michel D
many vertical blank periods occurred since the interrupt was disabled.
> But also this series is not fully tested. Apparently I have an issue yet
> with flip-vs-expired-vblank_* tests and pm_rpm basic tests.
Maybe some of the test failures are due to the abo
o jump
forward with drm_vblank_on/off(). It may not manifest itself with
current Intel hardware because that has a full 32-bit hardware frame
counter, turning the related calculations into no-ops. I haven't had
time to investigate this further yet.
--
Earthling Michel Dänzer
ch changes the DPMS state to on again. You can avoid
that with something like "sleep 1 && xset dpms force off".
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On 28.05.2015 18:03, Michel Dänzer wrote:
> On 28.05.2015 17:38, Daniel Vetter wrote:
>> On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
>>> On 27.05.2015 18:41, Daniel Vetter wrote:
>>>> On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wr
On 28.05.2015 17:38, Daniel Vetter wrote:
> On Thu, May 28, 2015 at 04:11:53PM +0900, Michel Dänzer wrote:
>> On 27.05.2015 18:41, Daniel Vetter wrote:
>>> On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
>>>> On 27.05.2015 18:04, Daniel Vette
On 27.05.2015 18:41, Daniel Vetter wrote:
> On Wed, May 27, 2015 at 06:21:24PM +0900, Michel Dänzer wrote:
>> On 27.05.2015 18:04, Daniel Vetter wrote:
>>> These should be functionally equivalent to the older per/post modeset
>>> functions, except that they block ou
e pending event cleanup can
> be done there, while drm_vblank_pre/post_modeset will be purely
> drm internal for the old UMS ioctl.
>
> Note that the kerneldoc for pre/post_modeset is wrong since as Michel
> Dänzer correctly pointed out it works if only using pre/post_modeset.
> The tr
e disabled after every IRQ and the user
> will enabled it again on the first query following the IRQ.
As I mentioned before, it might not be too hard to make querying the
current counter work without enabling the interrupt. But this looks like
a step in the right direction.
Acked-by: Mi
On 18.03.2015 11:53, Michel Dänzer wrote:
> On 18.03.2015 00:44, Chris Wilson wrote:
>> When userspace queries the current vblank for the CRTC, we can reply
>> with the cached value (using atomic reads to serialise with the vblank
>> interrupt as necessary) without having t
blank_count_and_time() doesn't return the correct sequence number
while the vblank interrupt is disabled, does it? It returns the sequence
number from the last time vblank_disable_and_save() was called (when the
vblank interrupt was disabled). That's why drm_vblank
On 31.07.2014 16:54, Daniel Vetter wrote:
> On Thu, Jul 31, 2014 at 3:14 AM, Michel Dänzer wrote:
>> I think it would be better to refactor drm_wait_vblank() than to
>> reinvent it.
>
> That's the ioctl implementation which spends most of its time decoding
> ioctl st
On 31.07.2014 00:21, Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
>> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
>>> On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
>>>> On 30.07.2014 17:22,
n ditch
> the max_vblank_counter check again.
>
> v4: Review from Michel Dänzer:
> - Restore lost notes about v3:
> - Spelling in kerneldoc.
> - Inline wait_event condition.
> - s/vblank_wait/wait_one_vblank/
>
> Cc: Michel Dänzer
> Cc: Ville Syrjälä
> Signed-off-
On 30.07.2014 17:22, Daniel Vetter wrote:
> On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
>> On 30.07.2014 06:32, Daniel Vetter wrote:
>>> + * due to lack of driver support or because the crtc is off.
>>> + */
>>> +void drm_cr
tc_vblank_wait);
> +
> +/**
Maybe the function names should be *_vblank_wait_next() or something to
clarify the purpose and reduce potential confusion versus drm_wait_vblank().
Looks good to me other than that.
--
Earthling Michel Dänzer| http://www.amd.com
Libre sof
On 29.05.2014 19:56, Daniel Vetter wrote:
> On Thu, May 29, 2014 at 6:11 AM, Michel Dänzer wrote:
>>
>>> We could rename the off/on to pre/post_modeset if you like, but then
>>> someone gets to audit all the other drivers. That someone isn't
>>> going to b
On 28.05.2014 20:19, Ville Syrjälä wrote:
> On Wed, May 28, 2014 at 06:12:54PM +0900, Michel Dänzer wrote:
>>
>> Digging out an ooold post of Daniel's...
>>
>> On 04.03.2014 18:13, Daniel Vetter wrote:
>>> On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel
Digging out an ooold post of Daniel's...
On 04.03.2014 18:13, Daniel Vetter wrote:
> On Tue, Feb 25, 2014 at 11:58:26AM +0900, Michel Dänzer wrote:
>>
>> When the pre/post-modeset hooks were originally added, it worked like
>> this: the pre-modeset hook enabled t
why we need two sets of
these instead of fixing any problems in one set.
[0] Though we certainly don't have as rigorous testing for that as you
guys do in intel-gpu-tools. Any chance some of that could be moved to
somewhere more generic?
--
Earthling M
ing drivers around modesetting
changes to allow the kernel to keep the vertical blank counters
consistent, since on many devices the hardware vertical blank counter is
reset to 0 at some point during modeset changes."
--
Earthling Michel Dänzer
On Mon, 2014-02-24 at 14:11 +0200, Ville Syrjälä wrote:
> On Mon, Feb 24, 2014 at 12:48:55PM +0900, Michel Dänzer wrote:
> > On Fre, 2014-02-21 at 21:03 +0200, ville.syrj...@linux.intel.com wrote:
> > >
> > > We can kill of the drm_vblank_{pre,post}_modeset() calls
onsistent across modesets, assuming the modeset resets the hardware
vblank counter.
--
Earthling Michel Dänzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
___
Intel-gfx mailing l
monotonic should probably be a bool rather than an int.
Looks good to me otherwise, as does patch 1.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
__
On Fre, 2012-10-05 at 16:59 +0300, Imre Deak wrote:
> On Fri, 2012-10-05 at 15:55 +0200, Michel Dänzer wrote:
> > On Fre, 2012-10-05 at 16:37 +0300, Imre Deak wrote:
> > > In practice we never want the timestamps for vblank and page flip events
> > > to be affected
trouble is really necessary. I honestly can't
imagine any user of this API requiring non-monotonic timestamps and
breaking with monotonic ones. I think it was simply a mistake that we
didn't make them monotonic in the first place (or maybe it wasn't even
possible when this API was fir
89 matches
Mail list logo
