Re: [PATCH v2] dma-contiguous: define proper name for global cma region
Hi, On Thu, 3 Aug 2023 at 23:04, Pintu Agarwal wrote: > > Hi, > > On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote: > > > > On Tue, Aug 01, 2023 at 10:39:04PM -0700, John Stultz wrote: > > > So, forgive me, I've not had a chance to look into this, but my > > > recollection was "reserved" is the name we see on x86, but other names > > > are possibly provided via the dts node? > > > No, I think "reserved" is the name hard-coded (for all arch) in Kernel > for global-cma. > So, I don't think this is x86 specific. I am checking on arm32 itself. > When we can dma_alloc_coherent we see these in the logs (if dts region > is not present). > cma: cma_alloc(cma (ptrval), name: reserved, count 64, align 6) > Now, with this change we will see this: > cma: cma_alloc(cma (ptrval), name: global-cma-region, count 64, align 6) > > > Indeed, dma_contiguous_default_area can also be set through > > rmem_cma_setup, which then takes the name from DT. > > > I think this is a different case. If DT entry is present we get this: > Reserved memory: created CMA memory pool at 0x9800, name: name: > linux,cma, size 128 MiB > cma: cma_alloc(cma (ptrval), name: linux,cma, count 64, align 6) > > Here we are talking about the default hard-coded name in Kernel code > if DT is not defined. > So, in one of the boards, this DT entry was not present and it shows > as "reserved". > > > > I believe on the hikey board its "linux,cma" is the name, so forcing > > > it to reserved would break that. > > > > Yes, everywhere in the DT it's defined as "linux,cma". > You mean this also should be changed to "linux,cma-global-region" > everywhere with this change ? > > > > Maybe instead add a compat config option to force the cma name (so x86 > > > can set it to "default" if needed)? > > > Yes, having it in config is also a good option instead of hard-coding in > Kernel. > > > > I think we'll just need to leave it as-is. I with dma-heaps had never > > exposed the name to userspace, but we'll have to lіve with it now. > > Can you point me to the userspace utility we are talking about here ? > I think we should not worry much about userspace name exposure. > I guess it should fetch whatever is declared in Kernel or DTS, right ? Just to follow-up on this. For now, can we change the Kernel hard-coded value from "reserved" to "global-cma-region" ? Later, for the DTS defined name let it be "linux,cma" or change that also to "linux,global-cma-region" ? Will this make sense ?
Re: [PATCH v2] dma-contiguous: define proper name for global cma region
Hi, On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote: > > On Tue, Aug 01, 2023 at 10:39:04PM -0700, John Stultz wrote: > > So, forgive me, I've not had a chance to look into this, but my > > recollection was "reserved" is the name we see on x86, but other names > > are possibly provided via the dts node? > No, I think "reserved" is the name hard-coded (for all arch) in Kernel for global-cma. So, I don't think this is x86 specific. I am checking on arm32 itself. When we can dma_alloc_coherent we see these in the logs (if dts region is not present). cma: cma_alloc(cma (ptrval), name: reserved, count 64, align 6) Now, with this change we will see this: cma: cma_alloc(cma (ptrval), name: global-cma-region, count 64, align 6) > Indeed, dma_contiguous_default_area can also be set through > rmem_cma_setup, which then takes the name from DT. > I think this is a different case. If DT entry is present we get this: Reserved memory: created CMA memory pool at 0x9800, name: name: linux,cma, size 128 MiB cma: cma_alloc(cma (ptrval), name: linux,cma, count 64, align 6) Here we are talking about the default hard-coded name in Kernel code if DT is not defined. So, in one of the boards, this DT entry was not present and it shows as "reserved". > > I believe on the hikey board its "linux,cma" is the name, so forcing > > it to reserved would break that. > > Yes, everywhere in the DT it's defined as "linux,cma". You mean this also should be changed to "linux,cma-global-region" everywhere with this change ? > > Maybe instead add a compat config option to force the cma name (so x86 > > can set it to "default" if needed)? > Yes, having it in config is also a good option instead of hard-coding in Kernel. > > I think we'll just need to leave it as-is. I with dma-heaps had never > exposed the name to userspace, but we'll have to lіve with it now. Can you point me to the userspace utility we are talking about here ? I think we should not worry much about userspace name exposure. I guess it should fetch whatever is declared in Kernel or DTS, right ?
Re: [PATCH v2] dma-contiguous: define proper name for global cma region
Hi Christoph, Thank you so much for your review and comments. On Mon, 31 Jul 2023 at 16:51, Christoph Hellwig wrote: > > Hi Pintu, > > On Sat, Jul 29, 2023 at 08:05:15AM +0530, Pintu Kumar wrote: > > The current global cma region name defined as "reserved" > > which is misleading, creates confusion and too generic. > > > > Also, the default cma allocation happens from global cma region, > > so, if one has to figure out all allocations happening from > > global cma region, this seems easier. > > > > Thus, change the name from "reserved" to "global-cma-region". > > I agree that reserved is not a very useful name. Unfortuately the > name of the region leaks to userspace through cma_heap. > > So I think we need prep patches to hardcode "reserved" in > add_default_cma_heap first, and then remove the cma_get_name > first. Sorry, but I could not fully understand your comments. Can you please elaborate a little more what changes are required in cma_heap if we change "reserved" to "global-cma-region" ? You mean to say there are userspace tools that rely on this "reserved" naming for global cma ?
Re: imx6: i2c-transfer timeout issue after resume
On Fri, Oct 4, 2019 at 3:47 PM Pintu Agarwal wrote: > > Hi, > > On Sun, Sep 29, 2019 at 10:24 PM Pintu Agarwal wrote: > > > > > > > > On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal > > > wrote: > > > > > > > > Dear Philipp, > > > > > > > > I have a iMX6dl custom board with custom Linux Kernel 4.8. > > > > I have both LCD and HDMI connected to the board. > > > > And we are using weston/wayland as the display interface. > > > > In normal boot, both LCD and HDMI display is working fine. > > > > > > > > But, currently, for one of the requirement, I am trying to explore and > > > > support hibernation image booting on it. > > > > Currently, we are able to resume the system without display. > > > > Also, if we make the entire imx-drm as modules, and then install the > > > > modules after resume, even LCD is also coming up. > > > > But HDMI display is black out. > > > > > > I just found the main root cause of the HDMI screen blackout issue > after system resume. > * HDMI is trying to get EDID data from the monitor using I2C interface. > * But its seems i2c_transfer is getting timeout after 5 retries. > * Thus EDID data is failing, and HDMI could not able to detect the monitor. > > This is the logs: > > [ 441.104989] [drm:drm_helper_probe_single_connector_modes] > [CONNECTOR:29:HDMI-A-1] status updated from unknown to connected > [ 441.116080]: drm_helper_probe_single_connector_modes - inside - > else override_edid > [ 441.124416]: drm_helper_probe_single_connector_modes - inside - > else - drm_load_edid_firmware: count: 0 > [ 441.134546]: drm_helper_probe_single_connector_modes - calling - get_modes > [ 441.142157]: dw_hdmi_connector_get_modes : called > [ 441.147652]: dw_hdmi_connector_get_modes : called - calling -> drm_get_edid > [ 441.155346]: drm_do_probe_ddc_edid : called! > [ 441.660759]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 5 > [ 442.170758]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 4 > [ 442.680755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 3 > [ 443.190755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 2 > [ 443.700754]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 1 > [ 443.707989]: drm_get_edid : called - drm_probe_ddc - failed > [ 443.714303] dwhdmi-imx 12.hdmi: failed to get edid > > Is there any clue, how to resolve this i2c failure issue, after resume? > This does not happen in normal booting case. > > These are the steps I follow: > * Boot the system normally (without display) and install all imx-drm as > modules. > * Then uninstall the modules in reverse order. > * Take the snapshot of the system (suspend to disk). > * Reboot the system and boot with the image. > * Install all the modules again. > * Then launch the Weston. > * During the weston launch in the beginning we observe this error. > * Changing the subject to be more relevant. I need some pointers in debugging this i2c_transfer timeout issue, after system resume. I am not so much familiar with i2c, so I am looking for some clue here. i2c-experts (or pm experts), please help me to find the root cause and debug further. Thanks, Pintu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imx6: hdmi black screen issue after resume
Hi, On Sun, Sep 29, 2019 at 10:24 PM Pintu Agarwal wrote: > > > > > On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal wrote: > > > > > > Dear Philipp, > > > > > > I have a iMX6dl custom board with custom Linux Kernel 4.8. > > > I have both LCD and HDMI connected to the board. > > > And we are using weston/wayland as the display interface. > > > In normal boot, both LCD and HDMI display is working fine. > > > > > > But, currently, for one of the requirement, I am trying to explore and > > > support hibernation image booting on it. > > > Currently, we are able to resume the system without display. > > > Also, if we make the entire imx-drm as modules, and then install the > > > modules after resume, even LCD is also coming up. > > > But HDMI display is black out. > > > I just found the main root cause of the HDMI screen blackout issue after system resume. * HDMI is trying to get EDID data from the monitor using I2C interface. * But its seems i2c_transfer is getting timeout after 5 retries. * Thus EDID data is failing, and HDMI could not able to detect the monitor. This is the logs: [ 441.104989] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:29:HDMI-A-1] status updated from unknown to connected [ 441.116080]: drm_helper_probe_single_connector_modes - inside - else override_edid [ 441.124416]: drm_helper_probe_single_connector_modes - inside - else - drm_load_edid_firmware: count: 0 [ 441.134546]: drm_helper_probe_single_connector_modes - calling - get_modes [ 441.142157]: dw_hdmi_connector_get_modes : called [ 441.147652]: dw_hdmi_connector_get_modes : called - calling -> drm_get_edid [ 441.155346]: drm_do_probe_ddc_edid : called! [ 441.660759]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 5 [ 442.170758]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 4 [ 442.680755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 3 [ 443.190755]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 2 [ 443.700754]: drm_do_probe_ddc_edid : i2c_transfer: ret: -110, retry: 1 [ 443.707989]: drm_get_edid : called - drm_probe_ddc - failed [ 443.714303] dwhdmi-imx 12.hdmi: failed to get edid Is there any clue, how to resolve this i2c failure issue, after resume? This does not happen in normal booting case. These are the steps I follow: * Boot the system normally (without display) and install all imx-drm as modules. * Then uninstall the modules in reverse order. * Take the snapshot of the system (suspend to disk). * Reboot the system and boot with the image. * Install all the modules again. * Then launch the Weston. * During the weston launch in the beginning we observe this error. Regards, Pintu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imx6: hdmi black screen issue after resume
>
> On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal wrote:
> >
> > Dear Philipp,
> >
> > I have a iMX6dl custom board with custom Linux Kernel 4.8.
> > I have both LCD and HDMI connected to the board.
> > And we are using weston/wayland as the display interface.
> > In normal boot, both LCD and HDMI display is working fine.
> >
> > But, currently, for one of the requirement, I am trying to explore and
> > support hibernation image booting on it.
> > Currently, we are able to resume the system without display.
> > Also, if we make the entire imx-drm as modules, and then install the
> > modules after resume, even LCD is also coming up.
> > But HDMI display is black out.
> >
> > After, resume, when I try to launch the weston, I noticed the following
> > errors:
> > enabling vblank on crtc 0, ret: 0
> > drm_vblank_get: CALLED: vblank->refcount: 1
> > [ cut here ]
> > WARNING: at drivers/gpu/drm/drm_atomic_helper.c:1121
> > drm_atomic_helper_wait_for_vblanks+0x228/0x24c [drm_kms_helper]()
> > [CRTC:24] vblank wait timed out
> > .
> > [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR*
> > [CRTC:24:crtc-0] flip_done timed out
> >
> >
> > [00:06:42.600] Warning: computed repaint delay is insane: -5069 msec
> > [00:06:42.665] unexpectedly large timestamp jump (from 397522 to 402648)
> >
> >
> > And, when I try to reboot the system, the system does not reboot.
> > And I get the following error:
> > /wayland # reboot
> >
> > [17:55:01.180] destroy output while page flip pending
> > ...
> > imx-ipuv3 240.ipu: DC stop timeout after 50 ms
> >
> >
> > -
> > If you have any clue about this issue, please let me know.
> >
> > Any help will be really appreciated!
> >
> >
> > Thank You!
> >
> > Regards,
> > Pintu
Hi All,
I need some help, on the above issue.
Finally, I could boil down the issue to be vblank refcount issue.
After system resume, vblank ref count is getting screwed up, because
of which vblank_enable is not happening.
As per below code path: drivers/gpu/drm/drm_vblank.c:
drm_vblank_get()
{
[...]
/* Going from 0->1 means we have to enable interrupts again */
if (atomic_add_return(1, >refcount) == 1) {
ret = drm_vblank_enable(dev, pipe);
} else {
if (!vblank->enabled) {
atomic_dec(>refcount);
ret = -EINVAL;
}
}
[...]
First time, everything seems fine.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 0, vblank-enabled: 0
..
drm_vblank_enable: calling - enable_vblank
enabling vblank on crtc 0, ret: 0
...
But, after resume, somewhere during HDMI initialization, the refcount
is getting incremented.
drm_vblank_get: CALLED: pipe: 0, vblank->refcount: 1, vblank-enabled: 1
Thus, due to the above logic, drm_vblank_enable() will not be called,
if previous refcount is not 0.
What I further noticed is that, after resume, during hdmi_setup the
refcount is automatically getting updated.
drm_update_vblank_count - storing vblank count: diff: 1
This does not happen in normal case.
Now, I am not sure, why the vblank counter is getting incremented
during hdmi setup.
Is it like, hdmi setup is taking slightly longer time for
initialization, after resume??
Because of which the vblank timestamp counter is getting disturbed.
If anybody observed this issue, or aware about the fixes, please let me know.
It will be of great help.
Meanwhile, I am further continue to debug this more..
Regards,
Pintu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: imx6: hdmi black screen issue after resume
Dear Philipp, Can you reply to my issue below? It will be of great help! Regards, Pintu On Mon, Sep 23, 2019 at 1:28 PM Pintu Agarwal wrote: > > Dear Philipp, > > I have a iMX6dl custom board with custom Linux Kernel 4.8. > I have both LCD and HDMI connected to the board. > And we are using weston/wayland as the display interface. > In normal boot, both LCD and HDMI display is working fine. > > But, currently, for one of our customer, I am trying to explore and > support snapshot image booting on it. > Currently, we are able to resume the system without display. > Also, if we make the entire imx-drm as modules, and then install the > modules are resume, even LCD is also coming up. > But HDMI display is black out. > > After, resume, when I try to launch the weston, I noticed the following > errors: > enabling vblank on crtc 0, ret: 0 > [PINTU]: drm_vblank_get: CALLED: vblank->refcount: 1 > [ cut here ] > WARNING: at drivers/gpu/drm/drm_atomic_helper.c:1121 > drm_atomic_helper_wait_for_vblanks+0x228/0x24c [drm_kms_helper]() > [CRTC:24] vblank wait timed out > . > [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* > [CRTC:24:crtc-0] flip_done timed out > > > [00:06:42.600] Warning: computed repaint delay is insane: -5069 msec > [00:06:42.665] unexpectedly large timestamp jump (from 397522 to 402648) > > > And, when I try to reboot the system, the system does not reboot. > And I get the following error: > /wayland # reboot > > [17:55:01.180] destroy output while page flip pending > ... > imx-ipuv3 240.ipu: DC stop timeout after 50 ms > > > - > If you have any clue about this issue, please let me know. > > Any help will be really appreciated! > > > Thank You! > > Regards, > Pintu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: dpms mode change with wayland on iMX.6
On Mon, May 27, 2019 at 3:42 PM Pintu Agarwal wrote:
>
> On Mon, May 27, 2019 at 12:41 PM Pintu Agarwal wrote:
> >
> > Dear All,
> >
> > I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
> > platform running.
> > The board is connected to one LCD screen and one HDMI monitor.
> > It have DRM + Wayland setup for display.
> > Also, I noticed that it have two dri interface:
> > /dev/dri/card0
> > /dev/dri/card1
> >
> > I am not very familiar with Linux Graphics/Display subsystem, so I am
> > looking for some help here.
> >
> > My requirement is that I have turn off HDMI display screen using a
> > command line utility or test program.
> > I learn that for X-server we can use xset : xset dpms force off (and
> > it works on my ubuntu desktop with 16.04).
> >
> > However this command does not exists on my board.
> > So, my question is:
> > Is there any equivalent DPMS commands for Wayland/Wetson?
> >
> > -
> > Further, in order to explore more, I cloned libdrm code from here:
> > url = https://gitlab.freedesktop.org/mesa/drm
> >
> > Then I found some test utility under: drm/tests folder.
> > After exploring more, and few modification, somehow I could able to
> > cross-compile "proptest" for my board using below:
> > arm-linux-gnueabi-gcc -o proptest.out proptest.c
> > -I./target/libdrm_include/ -L./target/libdrm_lib/ -ldrm
> >
> > I found that "/dev/dri/card0" is not working with this test.
> > So, I changed the test utility like this:
> > fd = drmOpen("imx-drm", NULL);
> > OR
> > fd = open("/dev/dri/card1", O_RDWR);
> >
> > When I default run it on my board, I see that "Connector_id: 29" is
> > showing for the HDMI display and it can support DPMS property.
> > {{{
> > Connector 29 (11-1)
> > 1 EDID:
> > flags: immutable blob
> > blobs:
> >
> > value:
> > XXX
> > 2 DPMS:
> > flags: enum
> > enums: On=0 Standby=1 Suspend=2 Off=3
> > value: 0
> > CRTC 24
> > CRTC 27
> > }}}
> >
> > Then, when I try to run it using below command:
> > # ./proptest.out 29 connector 2 3
> >
> > The program just returns successfully without any errors, but nothing
> > happens. The display does not turns off.
> > I saw that in my kernel 3.10 the ioctl(DRM_IOCTL_MODE_SETPROPERTY) is
> > already supported under DRM.
> >
> > So, I am wondering what is the right way to verify DPMS mode property
> > on wayland ?
> >
> > If anybody have any suggestions, please help me.
> >
> >
> > Thanks,
> > Pintu
>
> + etna...@lists.freedesktop.org
One more point:
Although it is having Kernel 3.10, but the DRM modules were upgraded
to Kernel 4.9.xx from mainline.
So, latest DRM changes are already applied.
Thanks,
Pintu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: dpms mode change with wayland on iMX.6
On Mon, May 27, 2019 at 12:41 PM Pintu Agarwal wrote:
>
> Dear All,
>
> I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
> platform running.
> The board is connected to one LCD screen and one HDMI monitor.
> It have DRM + Wayland setup for display.
> Also, I noticed that it have two dri interface:
> /dev/dri/card0
> /dev/dri/card1
>
> I am not very familiar with Linux Graphics/Display subsystem, so I am
> looking for some help here.
>
> My requirement is that I have turn off HDMI display screen using a
> command line utility or test program.
> I learn that for X-server we can use xset : xset dpms force off (and
> it works on my ubuntu desktop with 16.04).
>
> However this command does not exists on my board.
> So, my question is:
> Is there any equivalent DPMS commands for Wayland/Wetson?
>
> -
> Further, in order to explore more, I cloned libdrm code from here:
> url = https://gitlab.freedesktop.org/mesa/drm
>
> Then I found some test utility under: drm/tests folder.
> After exploring more, and few modification, somehow I could able to
> cross-compile "proptest" for my board using below:
> arm-linux-gnueabi-gcc -o proptest.out proptest.c
> -I./target/libdrm_include/ -L./target/libdrm_lib/ -ldrm
>
> I found that "/dev/dri/card0" is not working with this test.
> So, I changed the test utility like this:
> fd = drmOpen("imx-drm", NULL);
> OR
> fd = open("/dev/dri/card1", O_RDWR);
>
> When I default run it on my board, I see that "Connector_id: 29" is
> showing for the HDMI display and it can support DPMS property.
> {{{
> Connector 29 (11-1)
> 1 EDID:
> flags: immutable blob
> blobs:
>
> value:
> XXX
> 2 DPMS:
> flags: enum
> enums: On=0 Standby=1 Suspend=2 Off=3
> value: 0
> CRTC 24
> CRTC 27
> }}}
>
> Then, when I try to run it using below command:
> # ./proptest.out 29 connector 2 3
>
> The program just returns successfully without any errors, but nothing
> happens. The display does not turns off.
> I saw that in my kernel 3.10 the ioctl(DRM_IOCTL_MODE_SETPROPERTY) is
> already supported under DRM.
>
> So, I am wondering what is the right way to verify DPMS mode property
> on wayland ?
>
> If anybody have any suggestions, please help me.
>
>
> Thanks,
> Pintu
+ etna...@lists.freedesktop.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
dpms mode change with wayland on iMX.6
Dear All,
I have a iMX.6 (arm 32) board with Linux Kernel 3.10 and debian
platform running.
The board is connected to one LCD screen and one HDMI monitor.
It have DRM + Wayland setup for display.
Also, I noticed that it have two dri interface:
/dev/dri/card0
/dev/dri/card1
I am not very familiar with Linux Graphics/Display subsystem, so I am
looking for some help here.
My requirement is that I have turn off HDMI display screen using a
command line utility or test program.
I learn that for X-server we can use xset : xset dpms force off (and
it works on my ubuntu desktop with 16.04).
However this command does not exists on my board.
So, my question is:
Is there any equivalent DPMS commands for Wayland/Wetson?
-
Further, in order to explore more, I cloned libdrm code from here:
url = https://gitlab.freedesktop.org/mesa/drm
Then I found some test utility under: drm/tests folder.
After exploring more, and few modification, somehow I could able to
cross-compile "proptest" for my board using below:
arm-linux-gnueabi-gcc -o proptest.out proptest.c
-I./target/libdrm_include/ -L./target/libdrm_lib/ -ldrm
I found that "/dev/dri/card0" is not working with this test.
So, I changed the test utility like this:
fd = drmOpen("imx-drm", NULL);
OR
fd = open("/dev/dri/card1", O_RDWR);
When I default run it on my board, I see that "Connector_id: 29" is
showing for the HDMI display and it can support DPMS property.
{{{
Connector 29 (11-1)
1 EDID:
flags: immutable blob
blobs:
value:
XXX
2 DPMS:
flags: enum
enums: On=0 Standby=1 Suspend=2 Off=3
value: 0
CRTC 24
CRTC 27
}}}
Then, when I try to run it using below command:
# ./proptest.out 29 connector 2 3
The program just returns successfully without any errors, but nothing
happens. The display does not turns off.
I saw that in my kernel 3.10 the ioctl(DRM_IOCTL_MODE_SETPROPERTY) is
already supported under DRM.
So, I am wondering what is the right way to verify DPMS mode property
on wayland ?
If anybody have any suggestions, please help me.
Thanks,
Pintu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
