On Wed, 26 Feb 2025 15:20:20 +0100, Chuck Lever wrote: > > On 2/26/25 9:16 AM, Takashi Iwai wrote: > > On Wed, 26 Feb 2025 15:11:04 +0100, > > Chuck Lever wrote: > >> > >> On 2/26/25 3:38 AM, Takashi Iwai wrote: > >>> On Sun, 23 Feb 2025 16:18:41 +0100, > >>> Chuck Lever wrote: > >>>> > >>>> On 2/23/25 3:53 AM, Takashi Iwai wrote: > >>>>> [ resent due to a wrong address for regression reporting, sorry! ] > >>>>> > >>>>> Hi, > >>>>> > >>>>> we received a bug report showing the regression on 6.13.1 kernel > >>>>> against 6.13.0. The symptom is that Chrome and VSCode stopped working > >>>>> with Gnome Scaling, as reported on openSUSE Tumbleweed bug tracker > >>>>> https://bugzilla.suse.com/show_bug.cgi?id=1236943 > >>>>> > >>>>> Quoting from there: > >>>>> """ > >>>>> I use the latest TW on Gnome with a 4K display and 150% > >>>>> scaling. Everything has been working fine, but recently both Chrome > >>>>> and VSCode (installed from official non-openSUSE channels) stopped > >>>>> working with Scaling. > >>>>> .... > >>>>> I am using VSCode with: > >>>>> `--enable-features=UseOzonePlatform --enable-features=WaylandWindowDecorations --ozone-platform-hint=auto` and for Chrome, I select `Preferred Ozone platform` == `Wayland`. > >>>>> """ > >>>>> > >>>>> Surprisingly, the bisection pointed to the backport of the commit > >>>>> b9b588f22a0c049a14885399e27625635ae6ef91 ("libfs: Use d_children list > >>>>> to iterate simple_offset directories"). > >>>>> > >>>>> Indeed, the revert of this patch on the latest 6.13.4 was confirmed to > >>>>> fix the issue. Also, the reporter verified that the latest 6.14-rc > >>>>> release is still affected, too. > >>>>> > >>>>> For now I have no concrete idea how the patch could break the behavior > >>>>> of a graphical application like the above. Let us know if you need > >>>>> something for debugging. (Or at easiest, join to the bugzilla entry > >>>>> and ask there; or open another bug report at whatever you like.) > >>>>> > >>>>> BTW, I'll be traveling tomorrow, so my reply will be delayed. > >>>>> > >>>>> > >>>>> thanks, > >>>>> > >>>>> Takashi > >>>>> > >>>>> #regzbot introduced: b9b588f22a0c049a14885399e27625635ae6ef91 > >>>>> #regzbot monitor: https://bugzilla.suse.com/show_bug.cgi?id=1236943 > >>>> > >>>> We received a similar report a few days ago, and are likewise puzzled at > >>>> the commit result. Please report this issue to the Chrome development > >>>> team and have them come up with a simple reproducer that I can try in my > >>>> own lab. I'm sure they can quickly get to the bottom of the application > >>>> stack to identify the misbehaving interaction between OS and app. > >>> > >>> Do you know where to report to? > >> > >> You'll need to drive this, since you currently have a working > >> reproducer. > > > > No, I don't have, I'm merely a messenger. > > Whoever was the original reporter has the ability to reproduce this and > answer any questions the Chrome team might have. Please have them drive > this. I'm already two steps removed, so it doesn't make sense for me to > report a problem for which I have no standing. Yeah, I'm going to ask the original reporter, but this is still not perfect at all; namely, you'll be missed in the loop. e.g. who can answer to the questions from Chrome team about the breakage commit? That's why I asked you posting it previously. If it has to be done by the original reporter, at least, may your name / mail be put as the contact for the kernel stuff in the report? thanks, Takashi
