qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Phil Dennis-Jordan <lists@philjordan.eu>
To: "Philippe Mathieu-Daudé" <philmd@linaro.org>
Cc: qemu-devel@nongnu.org, "Volker Rümelin" <vr_qemu@t-online.de>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Peter Maydell" <peter.maydell@linaro.org>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Phil Dennis-Jordan" <phil@philjordan.eu>,
	"Akihiko Odaki" <akihiko.odaki@daynix.com>
Subject: Re: [PATCH-for-9.2] ui/cocoa: Temporarily ignore annoying deprecated declaration warnings
Date: Thu, 21 Nov 2024 15:35:15 +0100	[thread overview]
Message-ID: <CAGCz3vtkJS0Fgx_+1qJbUkYAxJ3WPvhEBxJ7P4T1a-g34KV1RA@mail.gmail.com> (raw)
In-Reply-To: <20241121131954.98949-1-philmd@linaro.org>

[-- Attachment #1: Type: text/plain, Size: 4990 bytes --]

As we're talking about macOS-only code I'd perhaps have used '#pragma clang
diagnostic' rather than the GCC versions, but clang seems to understand
these just fine too. (Plus, we very much intend for these to be genuinely
temporary.)

Reviewed-by: Phil Dennis-Jordan <phil@philjordan.eu>
Tested-by: Phil Dennis-Jordan <phil@philjordan.eu>

I'll try to find some spare cycles to come up with a clean solution to the
deprecation issue towards the end of the year. I need to research the
available alternative APIs for another project anyway.

I think part of the reason for the deprecation is that most modern Macs (as
with other modern laptop and desktop computers) actually use a variable
display frame rate, so the concept of a "native" frame rate is no longer
well-defined. In an ideal world the frame rate would be something that's
negotiable between the host UI and the virtual hardware.

For example, the macOS PV Graphics I've been working on integrating would
actually prefer a "push" arrangement where the guest/PV hardware notify the
host when the next frame is ready, rather than expecting a fixed-rate frame
refresh interrupt or similar. So when using that there would actually not
be any need for the display-linked timer at all if the UI is happy with the
hw calling dpy_gfx_update_full()/graphic_hw_update_done() proactively
whenever it has a new frame available. I'm not sure what the story is for
other display adapters in QEMU, but I can do a survey of that.


On Thu, 21 Nov 2024 at 14:20, Philippe Mathieu-Daudé <philmd@linaro.org>
wrote:

> These warnings are breaking some build configurations since 2 months
> now (https://gitlab.com/qemu-project/qemu/-/issues/2575):
>
>   ui/cocoa.m:662:14: error: 'CVDisplayLinkCreateWithCGDisplay' is
> deprecated: first deprecated in macOS 15.0 - use
> NSView.displayLink(target:selector:),
> NSWindow.displayLink(target:selector:), or
> NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
>     662 |         if (!CVDisplayLinkCreateWithCGDisplay(display,
> &displayLink)) {
>         |              ^
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:89:20:
> note: 'CVDisplayLinkCreateWithCGDisplay' has been explicitly marked
> deprecated here
>      89 | CV_EXPORT CVReturn CVDisplayLinkCreateWithCGDisplay(
>         |                    ^
>   ui/cocoa.m:663:29: error:
> 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' is deprecated: first
> deprecated in macOS 15.0 - use NSView.displayLink(target:selector:),
> NSWindow.displayLink(target:selector:), or
> NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
>     663 |             CVTime period =
> CVDisplayLinkGetNominalOutputVideoRefreshPeriod(displayLink);
>         |                             ^
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:182:18:
> note: 'CVDisplayLinkGetNominalOutputVideoRefreshPeriod' has been explicitly
> marked deprecated here
>     182 | CV_EXPORT CVTime
> CVDisplayLinkGetNominalOutputVideoRefreshPeriod( CVDisplayLinkRef
> CV_NONNULL displayLink );
>         |                  ^
>   ui/cocoa.m:664:13: error: 'CVDisplayLinkRelease' is deprecated: first
> deprecated in macOS 15.0 - use NSView.displayLink(target:selector:),
> NSWindow.displayLink(target:selector:), or
> NSScreen.displayLink(target:selector:)  [-Werror,-Wdeprecated-declarations]
>     664 |             CVDisplayLinkRelease(displayLink);
>         |             ^
>
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:249:16:
> note: 'CVDisplayLinkRelease' has been explicitly marked deprecated here
>     249 | CV_EXPORT void CVDisplayLinkRelease( CV_RELEASES_ARGUMENT
> CVDisplayLinkRef CV_NULLABLE displayLink );
>         |                ^
>   3 errors generated.
>
> For the next release, ignore the warnings using #pragma directives.
> At least until we figure the correct new API usage.
>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> ---
>  ui/cocoa.m | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/ui/cocoa.m b/ui/cocoa.m
> index 4c2dd33532..0422dafde4 100644
> --- a/ui/cocoa.m
> +++ b/ui/cocoa.m
> @@ -639,6 +639,9 @@ - (void) updateBounds
>      [self setBoundsSize:NSMakeSize(screen.width, screen.height)];
>  }
>
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +
>  - (void) updateUIInfoLocked
>  {
>      /* Must be called with the BQL, i.e. via updateUIInfo */
> @@ -685,6 +688,8 @@ - (void) updateUIInfoLocked
>      dpy_set_ui_info(dcl.con, &info, TRUE);
>  }
>
> +#pragma GCC diagnostic pop
> +
>  - (void) updateUIInfo
>  {
>      if (!allow_events) {
> --
> 2.45.2
>
>
>

[-- Attachment #2: Type: text/html, Size: 5946 bytes --]

  reply	other threads:[~2024-11-21 14:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-21 13:19 [PATCH-for-9.2] ui/cocoa: Temporarily ignore annoying deprecated declaration warnings Philippe Mathieu-Daudé
2024-11-21 14:35 ` Phil Dennis-Jordan [this message]
2024-11-27  7:07   ` Akihiko Odaki
2024-12-03 15:39 ` Philippe Mathieu-Daudé

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGCz3vtkJS0Fgx_+1qJbUkYAxJ3WPvhEBxJ7P4T1a-g34KV1RA@mail.gmail.com \
    --to=lists@philjordan.eu \
    --cc=akihiko.odaki@daynix.com \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=phil@philjordan.eu \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vr_qemu@t-online.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).