Re: [Metamath] Re: Shortest possible axiom for propositional calculus

[Mario Carneiro]

On Thu, Jun 6, 2024 at 11:07 AM Gino Giotto 
wrote:

> So this is the linked single NAND axiom for propositional calculus by
> Stephen Wolfram:
>
> ((p·q)·r)·(p·((p·r)·p))=r
>
> My question is: how would this translate into Metamath?
>

To answer this question directly, here's a metamath axiomatization of
wolfram's axiom system and a proof of step 1:

$c term wff |- = ( ) $.
$v p q r s ph $.
tp $f term p $.
tq $f term q $.
tr $f term r $.
ts $f term s $.
wph $f wff ph $.
weq $a wff p = q $. $( equality $)
tna $a term ( p q ) $. $( nand $)

${ symm.1 $e |- p = q $.
   symm $a |- q = p $. $}
${ trans.1 $e |- p = q $.  trans.2 $e |- q = r $.
   trans $a |- p = r $. $}
${ naeq.1 $e |- p = q $.  naeq.2 $e |- r = s $.
   naeq $a |- ( p r ) = ( q s ) $. $}

ax $a |- ( ( ( p q ) r ) ( p ( ( p r ) p ) ) ) = r $.

refl $p |- p = p $=
  ( tna ax symm trans ) AAABABZAFBBZAGCZDHE $.

step1 $p |- ( p ( ( p q ) p ) ) = ( q ( ( p r ) ( ( ( p r ) ( p ( ( p q ) p
) ) ) ( p r ) ) ) ) $=
  ( tna ax symm refl naeq trans )
AABDADDZACDZBDJDZKKJDKDDZDZBMDNJKBJEFLBMMACBE
  MGHI $.

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJSvt8SpjWuMpPCsEwZbFieEGHXTKnD9e3Ur7a%3DghDTBg6A%40mail.gmail.com.

Re: [Metamath] Re: Shortest possible axiom for propositional calculus

[Mario Carneiro]

Wolfram's axiom is in "equational logic". That means that all theorems are
of the form |- A = B, and the rules of inference are more or less:

* symmetry: If |- A = B then |- B = A
* instantiation: If |- A = B then |- A[sigma] = B[sigma] for any
substitution sigma to the variables in A and B
* substitution: If |- A = B and |- C[A] = D[A] then |- C[B] = D[B] where
C[_] and D[_] are contexts, i.e. terms with a hole in them which are filled
by A and B respectively

For example, I asked FindEquationalProof to prove |- (a|a)|(a|a) = a from
wolfram's axiom |- ((a|b)|c)|(a|((a|c)|a)) = c, and the first step was:

|- a|((a|b)|a) = b|((a|c)|(((a|c)|(a|((a|b)|a)))|(a|c)))

which is obtained from the rules above as:

1. |- ((a|b)|c)|(a|((a|c)|a)) = c   (axiom)
2. |- (((a|b)|c)|(a|((a|c)|a)))|((a|b)|(((a|b)|(a|((a|c)|a)))|(a|b))) =
a|((a|c)|a)   (instantiate a -> a|b, b -> c, c -> a|((a|c)|a) in 1)
3. |- c|((a|b)|(((a|b)|(a|((a|c)|a)))|(a|b))) = a|((a|c)|a)   (substitute 1
in 2, with pattern _|((a|b)|(((a|b)|(a|((a|c)|a)))|(a|b))) = a|((a|c)|a))
4. |- a|((a|c)|a) = c|((a|b)|(((a|b)|(a|((a|c)|a)))|(a|b)))   (symmetry 3)
5. |- a|((a|b)|a) = b|((a|c)|(((a|c)|(a|((a|b)|a)))|(a|c)))   (instantiate
a -> a, b -> c, c -> b)

(this is actually one step in wolfram's logic, which does certain
operations like symmetry and bound variable renaming in zero steps).

This is a fundamentally different kind of logic from metamath's usual FOL
style inferential system, where the proof goals are of the form |- phi and
modus ponens is traditionally the main inference rule. See ql.mm (
https://us.metamath.org/qleuni/mmtheorems1.html#ax-a1) for an example of an
equational logic implemented in metamath.




On Thu, Jun 6, 2024 at 6:34 PM samiro.d...@rwth-aachen.de <
samiro.disc...@rwth-aachen.de> wrote:

> > he stated that his axiom has 15 symbols
>
> Upon rereading Wolfram's articles (including
> https://www.wolfram.com/language/12/algebraic-computation/the-shortest-possible-axiom-for-boolean-logic.html),
> I couldn't even confirm this (I read them several years ago).
> Claiming that one found "The Shortest Possible Axiom for Boolean Logic"
> without even stating for which rules of inference and how long the axiom is
> and by which metric seems rather chaotic and bold..
>
> But the metric I assumed is used here:
> https://www.cs.unm.edu/~mccune/papers/basax/v12.pdf
> On page 3, Wolfram's single axiom is denoted as (Sh₁), and they write:
>
> > Equation (Sh₁) is a member of a list of 25 candidates sent to us by
> Stephen Wolfram [17], who asked whether Otter could prove any of the
> candidates to be single axioms. [...]
> > In Section 4 we show that (Sh₁), *which has length 15*, is a shortest
> single axiom in terms of the Sheffer stroke, and in Section 5 we narrow the
> list of possible length-15 Sheffer axioms to 16 candidates."
>
> You could read that paper and references in order to understand what these
> systems really are.
>
>
> samiro.d...@rwth-aachen.de schrieb am Donnerstag, 6. Juni 2024 um
> 17:32:12 UTC+2:
>
>> > This is what makes me skeptical.
>>
>>
>> And rightfully so. These kind of systems with weird rules are a thing, as
>> you can see for example at
>> https://web.ics.purdue.edu/~dulrich/Twenty-six-open-questions-page.htm
>> (where NAND is calleld "Sheffer's joint-denial operator") or
>> https://en.wikipedia.org/wiki/Nicod%27s_axiom (which mentions a rule "Nicod's
>> modus ponens"), but rules should indeed always be stated explicitly.
>> Wolfram's article wouldn't pass peer review without modifications.
>>
>>
>> > Thierry second interpretation makes more sense to me.
>>
>>
>> But that one is definitely false since a rule with more than 0 premises
>> is not an axiom, and furthermore he stated that his axiom has 15 symbols,
>> i.e. "=" is a single operator.
>>
>> Moreover, the point was to state a single-axiom system. But given that
>> for handing both '<->' and '-/\' you most likely need multiple rules,
>> the whole approach is moot. Since when using multiple rules you do not need
>> *any* axioms for propositional logic (as we know, for example, from natural
>> deduction systems).
>>
>>
>> --
>> *Von:* meta...@googlegroups.com  im Auftrag
>> von Gino Giotto 
>> *Gesendet:* Donnerstag, 6. Juni 2024 17:16:50
>> *An:* Metamath
>>
>> *Betreff:* Re: [Metamath] Re: Shortest possible axiom for propositional
>> calculus
>> >  Whichever rule(s) Stephen Wolfram's system implicitly use(s), he
>> didn't even write them down explicitly — apparently not aware that this is
>> important, but possibly hiding the actual complex definition of the system.
>>
>> This is what makes me skeptical. By reading his post, he claims that his
>> axiom is all you need, but this doesn't look right to me. Let's assume that
>> his "=" is really the same thing as the metamath  "<-> " and go forward
>> to prove all true propositional statements. Now let's say I want to prove
>> the simple tautology "|-  ( ph -/\ ( ph -/\ ph ) )", to 

Re: [PATCH v2] drm/amdgpu: Fix the BO release clear memory warning

[Mario Limonciello]

On 6/6/2024 15:04, Arunpravin Paneer Selvam wrote:

This happens when the amdgpu_bo_release_notify running
before amdgpu_ttm_set_buffer_funcs_status set the buffer
funcs to enabled.

check the buffer funcs enablement before calling the fill
buffer memory.

v2:(Christian)
   - Apply it only for GEM buffers and since GEM buffers are only
 allocated/freed while the driver is loaded we never run into
 the issue to clear with buffer funcs disabled.

Log snip:
[6.036477] [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory 
with ring turned off.
[6.036667] [ cut here ]
[6.036668] WARNING: CPU: 3 PID: 370 at 
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:1355 
amdgpu_bo_release_notify+0x201/0x220 [amdgpu]
[6.036767] Modules linked in: hid_generic amdgpu(+) amdxcp drm_exec 
gpu_sched drm_buddy i2c_algo_bit usbhid drm_suballoc_helper drm_display_helper 
hid sd_mod cec rc_core drm_ttm_helper ahci ttm nvme libahci drm_kms_helper 
nvme_core r8169 xhci_pci libata t10_pi xhci_hcd realtek crc32_pclmul 
crc64_rocksoft mdio_devres crc64 drm crc32c_intel scsi_mod usbcore thunderbolt 
crc_t10dif i2c_piix4 libphy crct10dif_generic crct10dif_pclmul crct10dif_common 
scsi_common usb_common video wmi gpio_amdpt gpio_generic button
[6.036793] CPU: 3 PID: 370 Comm: (udev-worker) Not tainted 6.8.7-dirty #1
[6.036795] Hardware name: ASRock X670E Taichi/X670E Taichi, BIOS 2.10 
03/26/2024
[6.036796] RIP: 0010:amdgpu_bo_release_notify+0x201/0x220 [amdgpu]
[6.036891] Code: 0b e9 af fe ff ff 48 ba ff ff ff ff ff ff ff 7f 31 f6 4c 89 e7 
e8 7f 2f 7a d8 eb 98 e8 18 28 7a d8 eb b2 0f 0b e9 58 fe ff ff <0f> 0b eb a7 be 
03 00 00 00 e8 e1 89 4e d8 eb 9b e8 aa 4d ad d8 66
[6.036892] RSP: 0018:bbe140d1f638 EFLAGS: 00010282
[6.036894] RAX: ffea RBX: 90cba9e4e858 RCX: 90dabde38c28
[6.036895] RDX:  RSI: dfff RDI: 0001
[6.036896] RBP: 90cba980ef40 R08:  R09: bbe140d1f3c0
[6.036896] R10: bbe140d1f3b8 R11: 0003 R12: 90cba9e4e800
[6.036897] R13: 90cba9e4e958 R14: 90cba980ef40 R15: 0258
[6.036898] FS:  7f2bd1679d00() GS:90da7e2c() 
knlGS:
[6.036899] CS:  0010 DS:  ES:  CR0: 80050033
[6.036900] CR2: 55a9b0f7299d CR3: 00011bb6e000 CR4: 00750ef0
[6.036901] PKRU: 5554
[6.036901] Call Trace:
[6.036903]  
[6.036904]  ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu]
[6.036998]  ? __warn+0x81/0x130
[6.037002]  ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu]
[6.037095]  ? report_bug+0x171/0x1a0
[6.037099]  ? handle_bug+0x3c/0x80
[6.037101]  ? exc_invalid_op+0x17/0x70
[6.037103]  ? asm_exc_invalid_op+0x1a/0x20
[6.037107]  ? amdgpu_bo_release_notify+0x201/0x220 [amdgpu]
[6.037199]  ? amdgpu_bo_release_notify+0x14a/0x220 [amdgpu]
[6.037292]  ttm_bo_release+0xff/0x2e0 [ttm]
[6.037297]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.037299]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.037301]  ? ttm_resource_move_to_lru_tail+0x140/0x1e0 [ttm]
[6.037306]  amdgpu_bo_free_kernel+0xcb/0x120 [amdgpu]
[6.037399]  dm_helpers_free_gpu_mem+0x41/0x80 [amdgpu]
[6.037544]  dcn315_clk_mgr_construct+0x198/0x7e0 [amdgpu]
[6.037692]  dc_clk_mgr_create+0x16e/0x5f0 [amdgpu]
[6.037826]  dc_create+0x28a/0x650 [amdgpu]
[6.037958]  amdgpu_dm_init.isra.0+0x2d5/0x1ec0 [amdgpu]
[6.038085]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038087]  ? prb_read_valid+0x1b/0x30
[6.038089]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038090]  ? console_unlock+0x78/0x120
[6.038092]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038094]  ? vprintk_emit+0x175/0x2c0
[6.038095]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038097]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038098]  ? dev_printk_emit+0xa5/0xd0
[6.038104]  dm_hw_init+0x12/0x30 [amdgpu]
[6.038209]  amdgpu_device_init+0x1e50/0x2500 [amdgpu]
[6.038308]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038310]  ? srso_alias_return_thunk+0x5/0xfbef5
[6.038313]  amdgpu_driver_load_kms+0x19/0x190 [amdgpu]
[6.038409]  amdgpu_pci_probe+0x18b/0x510 [amdgpu]
[6.038505]  local_pci_probe+0x42/0xa0
[6.038508]  pci_device_probe+0xc7/0x240
[6.038510]  really_probe+0x19b/0x3e0
[6.038513]  ? __pfx___driver_attach+0x10/0x10
[6.038514]  __driver_probe_device+0x78/0x160
[6.038516]  driver_probe_device+0x1f/0x90
[6.038517]  __driver_attach+0xd2/0x1c0
[6.038519]  bus_for_each_dev+0x85/0xd0
[6.038521]  bus_add_driver+0x116/0x220
[6.038523]  driver_register+0x59/0x100
[6.038525]  ? __pfx_amdgpu_init+0x10/0x10 [amdgpu]
[6.038618]  do_one_initcall+0x58/0x320
[6.038621]  do_init_module+0x60/0x230
[6.038624]  init_module_from_file+0x89/0xe0
[6.038628]  idempotent_init_module+0x120/0x2b0
[

[Bug 2067997] Re: Lenovo T14 Gen3 AMD laptop freezes shortly after suspend resume

[Mario Limonciello]

*** This bug is a duplicate of bug 2064595 ***
https://bugs.launchpad.net/bugs/2064595

** This bug has been marked a duplicate of bug 2064595
   S2idle regression

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067997

Title:
  Lenovo T14 Gen3 AMD laptop freezes shortly after suspend resume

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2067997/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [syzbot] [mm?] general protection fault in dequeue_hugetlb_folio_nodemask

[Mario Limonciello]

On 6/6/2024 09:39, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:0e1980c40b6e Add linux-next specific files for 20240531
git tree:   linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=166086f298
kernel config:  https://syzkaller.appspot.com/x/.config?x=d9c3ca4e54577b88
dashboard link: https://syzkaller.appspot.com/bug?extid=c019f68a83ef9b456444
compiler:   Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 
2.40
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12f4094a98
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15e1e43298

Downloadable assets:
disk image: 
https://storage.googleapis.com/syzbot-assets/44fb1d8b5978/disk-0e1980c4.raw.xz
vmlinux: 
https://storage.googleapis.com/syzbot-assets/a66ce5caf0b2/vmlinux-0e1980c4.xz
kernel image: 
https://storage.googleapis.com/syzbot-assets/8992fc8fe046/bzImage-0e1980c4.xz

The issue was bisected to:

commit cd94d1b182d2986378550c9087571991bfee01d4
Author: Mario Limonciello 
Date:   Thu May 2 18:32:17 2024 +

 dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 
users

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=176121c298
console output: https://syzkaller.appspot.com/x/log.txt?x=10e121c298

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c019f68a83ef9b456...@syzkaller.appspotmail.com
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU 
13.0.4/13.0.11 users")

Oops: general protection fault, probably for non-canonical address 
0xdc000489:  [#1] PREEMPT SMP KASAN PTI
KASAN: probably user-memory-access in range 
[0x2448-0x244f]
CPU: 1 PID: 5089 Comm: syz-executor257 Not tainted 
6.10.0-rc1-next-20240531-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
04/02/2024
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c 
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58 
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026ef
RDX:  RSI:  RDI: 
RBP: c900035ef858 R08: 81f5e070 R09: f520006bdee8
R10: dc00 R11: f520006bdee8 R12: 
R13: dc00 R14:  R15: 
FS:  64010380() GS:8880b950() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 005fdeb8 CR3: 7bd96000 CR4: 003506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  
  alloc_hugetlb_folio_nodemask+0xae/0x3f0 mm/hugetlb.c:2603
  memfd_alloc_folio+0x15e/0x390 mm/memfd.c:75
  memfd_pin_folios+0x1066/0x1720 mm/gup.c:3864
  udmabuf_create+0x658/0x11c0 drivers/dma-buf/udmabuf.c:353
  udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:420 [inline]
  udmabuf_ioctl+0x304/0x4f0 drivers/dma-buf/udmabuf.c:451
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5151a7a369
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 
48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 
c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffd962ee9e8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd962eebb8 RCX: 7f5151a7a369
RDX: 22c0 RSI: 40187542 RDI: 0003
RBP: 7f5151aed610 R08: 7ffd962eebb8 R09: 7ffd962eebb8
R10: 7ffd962eebb8 R11: 0246 R12: 0001
R13: 7ffd962eeba8 R14: 0001 R15: 0001
  
Modules linked in:
---[ end trace  ]---
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c 
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58 
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 04

Re: [syzbot] [mm?] general protection fault in dequeue_hugetlb_folio_nodemask

[Mario Limonciello]

On 6/6/2024 09:39, syzbot wrote:

Hello,

syzbot found the following issue on:

HEAD commit:0e1980c40b6e Add linux-next specific files for 20240531
git tree:   linux-next
console+strace: https://syzkaller.appspot.com/x/log.txt?x=166086f298
kernel config:  https://syzkaller.appspot.com/x/.config?x=d9c3ca4e54577b88
dashboard link: https://syzkaller.appspot.com/bug?extid=c019f68a83ef9b456444
compiler:   Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 
2.40
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=12f4094a98
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15e1e43298

Downloadable assets:
disk image: 
https://storage.googleapis.com/syzbot-assets/44fb1d8b5978/disk-0e1980c4.raw.xz
vmlinux: 
https://storage.googleapis.com/syzbot-assets/a66ce5caf0b2/vmlinux-0e1980c4.xz
kernel image: 
https://storage.googleapis.com/syzbot-assets/8992fc8fe046/bzImage-0e1980c4.xz

The issue was bisected to:

commit cd94d1b182d2986378550c9087571991bfee01d4
Author: Mario Limonciello 
Date:   Thu May 2 18:32:17 2024 +

 dm/amd/pm: Fix problems with reboot/shutdown for some SMU 13.0.4/13.0.11 
users

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=176121c298
console output: https://syzkaller.appspot.com/x/log.txt?x=10e121c298

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+c019f68a83ef9b456...@syzkaller.appspotmail.com
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU 
13.0.4/13.0.11 users")

Oops: general protection fault, probably for non-canonical address 
0xdc000489:  [#1] PREEMPT SMP KASAN PTI
KASAN: probably user-memory-access in range 
[0x2448-0x244f]
CPU: 1 PID: 5089 Comm: syz-executor257 Not tainted 
6.10.0-rc1-next-20240531-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
04/02/2024
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c 
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58 
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 0489 RBX: 2448 RCX: 888026ef
RDX:  RSI:  RDI: 
RBP: c900035ef858 R08: 81f5e070 R09: f520006bdee8
R10: dc00 R11: f520006bdee8 R12: 
R13: dc00 R14:  R15: 
FS:  64010380() GS:8880b950() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 005fdeb8 CR3: 7bd96000 CR4: 003506f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  
  alloc_hugetlb_folio_nodemask+0xae/0x3f0 mm/hugetlb.c:2603
  memfd_alloc_folio+0x15e/0x390 mm/memfd.c:75
  memfd_pin_folios+0x1066/0x1720 mm/gup.c:3864
  udmabuf_create+0x658/0x11c0 drivers/dma-buf/udmabuf.c:353
  udmabuf_ioctl_create drivers/dma-buf/udmabuf.c:420 [inline]
  udmabuf_ioctl+0x304/0x4f0 drivers/dma-buf/udmabuf.c:451
  vfs_ioctl fs/ioctl.c:51 [inline]
  __do_sys_ioctl fs/ioctl.c:907 [inline]
  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
  entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f5151a7a369
Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 
48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 
c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:7ffd962ee9e8 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 7ffd962eebb8 RCX: 7f5151a7a369
RDX: 22c0 RSI: 40187542 RDI: 0003
RBP: 7f5151aed610 R08: 7ffd962eebb8 R09: 7ffd962eebb8
R10: 7ffd962eebb8 R11: 0246 R12: 0001
R13: 7ffd962eeba8 R14: 0001 R15: 0001
  
Modules linked in:
---[ end trace  ]---
RIP: 0010:zonelist_zone_idx include/linux/mmzone.h:1613 [inline]
RIP: 0010:next_zones_zonelist include/linux/mmzone.h:1644 [inline]
RIP: 0010:first_zones_zonelist include/linux/mmzone.h:1670 [inline]
RIP: 0010:dequeue_hugetlb_folio_nodemask+0x193/0xe40 mm/hugetlb.c:1362
Code: 13 9b a0 ff c7 44 24 14 00 00 00 00 83 7c 24 40 00 0f 85 97 0c 00 00 48 83 7c 
24 20 00 0f 85 45 09 00 00 48 89 d8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 58 
09 00 00 44 8b 33 44 89 f7 8b 5c 24
RSP: 0018:c900035ef720 EFLAGS: 00010002
RAX: 04

Re: [PATCH v4 5/5] backends/hostmem: Report error when memory size is unaligned

[Mario Casquero]

This patch has been successfully tested. Try to allocate some 2M
hugepages in the host, then boot up a VM with the memory size
unaligned and backed by a file, QEMU prompts the following message:
qemu-system-x86_64: backend 'memory-backend-file' memory size must be
multiple of 2 MiB

Tested-by: Mario Casquero 

On Wed, Jun 5, 2024 at 12:45 PM Michal Privoznik  wrote:
>
> If memory-backend-{file,ram} has a size that's not aligned to
> underlying page size it is not only wasteful, but also may lead
> to hard to debug behaviour. For instance, in case
> memory-backend-file and hugepages, madvise() and mbind() fail.
> Rightfully so, page is the smallest unit they can work with. And
> even though an error is reported, the root cause it not very
> clear:
>
>   qemu-system-x86_64: Couldn't set property 'dump' on 'memory-backend-file': 
> Invalid argument
>
> After this commit:
>
>   qemu-system-x86_64: backend 'memory-backend-file' memory size must be 
> multiple of 2 MiB
>
> Signed-off-by: Michal Privoznik 
> Reviewed-by: Philippe Mathieu-Daudé 
> Tested-by: Mario Casquero 
> ---
>  backends/hostmem.c | 10 ++
>  1 file changed, 10 insertions(+)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 012a8c190f..4d6c69fe4d 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -20,6 +20,7 @@
>  #include "qom/object_interfaces.h"
>  #include "qemu/mmap-alloc.h"
>  #include "qemu/madvise.h"
> +#include "qemu/cutils.h"
>  #include "hw/qdev-core.h"
>
>  #ifdef CONFIG_NUMA
> @@ -337,6 +338,7 @@ host_memory_backend_memory_complete(UserCreatable *uc, 
> Error **errp)
>  HostMemoryBackendClass *bc = MEMORY_BACKEND_GET_CLASS(uc);
>  void *ptr;
>  uint64_t sz;
> +size_t pagesize;
>  bool async = !phase_check(PHASE_LATE_BACKENDS_CREATED);
>
>  if (!bc->alloc) {
> @@ -348,6 +350,14 @@ host_memory_backend_memory_complete(UserCreatable *uc, 
> Error **errp)
>
>  ptr = memory_region_get_ram_ptr(>mr);
>  sz = memory_region_size(>mr);
> +pagesize = qemu_ram_pagesize(backend->mr.ram_block);
> +
> +if (!QEMU_IS_ALIGNED(sz, pagesize)) {
> +g_autofree char *pagesize_str = size_to_str(pagesize);
> +error_setg(errp, "backend '%s' memory size must be multiple of %s",
> +   object_get_typename(OBJECT(uc)), pagesize_str);
> +return;
> +}
>
>  if (backend->merge &&
>  qemu_madvise(ptr, sz, QEMU_MADV_MERGEABLE)) {
> --
> 2.44.1
>
>

[Bug 2067997] Re: Lenovo T14 Gen3 AMD laptop freezes shortly after suspend resume

[Mario Limonciello]

Should be a duplicate of that.  It was fixed in upstream 6.8.5, Ubuntu's
6.8.0-35 is still on 6.8.3.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2067997

Title:
  Lenovo T14 Gen3 AMD laptop freezes shortly after suspend resume

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2067997/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH v3 2/2] drm/amd: Add power_saving_policy drm property to eDP connectors

[Mario Limonciello]

When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.

When the `power_saving_policy` property is set to bit mask
"Require low latency" PSR should be disabled.

When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.

Signed-off-by: Mario Limonciello 
---
v2->v3:
 * Use `disallow_edp_enter_psr` instead
 * Drop case in dm_update_crtc_state()
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 3 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..cfb5220cf182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,10 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_power_saving_policy_property(adev_to_drm(adev),
+
DRM_MODE_POWER_SAVING_POLICY_ALL);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f1d67c6f4b98..5fd7210b2479 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,6 +6436,13 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   dm_new_state->abm_forbidden = val & 
DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   dm_new_state->abm_level = (dm_new_state->abm_forbidden || 
!amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   dm_new_state->psr_forbidden = val & 
DRM_MODE_REQUIRE_LOW_LATENCY;
+   ret = 0;
}
 
return ret;
@@ -6478,6 +6485,13 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   *val = 0;
+   if (dm_state->psr_forbidden)
+   *val |= DRM_MODE_REQUIRE_LOW_LATENCY;
+   if (dm_state->abm_forbidden)
+   *val |= DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   ret = 0;
}
 
return ret;
@@ -6504,9 +6518,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6530,10 +6547,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7704,6 +7727,13 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.

[PATCH v3 0/2] Add support for 'power saving policy' property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
with requests of "Require color accuracy" or "Require low latency"
that can be configured by the compositor.

When a driver advertises support for this property and the compositor
sets it to "Require color accuracy" then the driver will disable any power
saving features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Require color accuracy" then
this feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

Compositors can also request that low latency is critical which in
practice should cause PSR and PSR2 to be disabled.

When the compositor has restored the value back to no requirements then
the previous value that would have been programmed will be restored.

v2->v3:
 * Updates from Leo's comments (see individual patches)

The matching changes for the igt are here:
https://lore.kernel.org/dri-devel/2024050849.33343-1-mario.limoncie...@amd.com/

Mario Limonciello (2):
  drm: Introduce 'power saving policy' drm property
  drm/amd: Add power_saving_policy drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 drivers/gpu/drm/drm_connector.c   | 46 +
 include/drm/drm_connector.h   |  2 +
 include/drm/drm_mode_config.h |  5 ++
 include/uapi/drm/drm_mode.h   |  7 +++
 7 files changed, 111 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v3 0/2] Add support for 'power saving policy' property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
with requests of "Require color accuracy" or "Require low latency"
that can be configured by the compositor.

When a driver advertises support for this property and the compositor
sets it to "Require color accuracy" then the driver will disable any power
saving features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Require color accuracy" then
this feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

Compositors can also request that low latency is critical which in
practice should cause PSR and PSR2 to be disabled.

When the compositor has restored the value back to no requirements then
the previous value that would have been programmed will be restored.

v2->v3:
 * Updates from Leo's comments (see individual patches)

The matching changes for the igt are here:
https://lore.kernel.org/dri-devel/2024050849.33343-1-mario.limoncie...@amd.com/

Mario Limonciello (2):
  drm: Introduce 'power saving policy' drm property
  drm/amd: Add power_saving_policy drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 drivers/gpu/drm/drm_connector.c   | 46 +
 include/drm/drm_connector.h   |  2 +
 include/drm/drm_mode_config.h |  5 ++
 include/uapi/drm/drm_mode.h   |  7 +++
 7 files changed, 111 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v3 2/2] drm/amd: Add power_saving_policy drm property to eDP connectors

[Mario Limonciello]

When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.

When the `power_saving_policy` property is set to bit mask
"Require low latency" PSR should be disabled.

When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.

Signed-off-by: Mario Limonciello 
---
v2->v3:
 * Use `disallow_edp_enter_psr` instead
 * Drop case in dm_update_crtc_state()
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 3 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..cfb5220cf182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,10 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_power_saving_policy_property(adev_to_drm(adev),
+
DRM_MODE_POWER_SAVING_POLICY_ALL);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index f1d67c6f4b98..5fd7210b2479 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6436,6 +6436,13 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   dm_new_state->abm_forbidden = val & 
DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   dm_new_state->abm_level = (dm_new_state->abm_forbidden || 
!amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   dm_new_state->psr_forbidden = val & 
DRM_MODE_REQUIRE_LOW_LATENCY;
+   ret = 0;
}
 
return ret;
@@ -6478,6 +6485,13 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   *val = 0;
+   if (dm_state->psr_forbidden)
+   *val |= DRM_MODE_REQUIRE_LOW_LATENCY;
+   if (dm_state->abm_forbidden)
+   *val |= DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   ret = 0;
}
 
return ret;
@@ -6504,9 +6518,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6530,10 +6547,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7704,6 +7727,13 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.

[PATCH v3 1/2] drm: Introduce 'power saving policy' drm property

[Mario Limonciello]

The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.

Acked-by: Leo Li 
Signed-off-by: Mario Limonciello 
---
v2->v3:
* Add tag
---
 drivers/gpu/drm/drm_connector.c | 46 +
 include/drm/drm_connector.h |  2 ++
 include/drm/drm_mode_config.h   |  5 
 include/uapi/drm/drm_mode.h |  7 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..088a5874c7a4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
+   { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color 
accuracy" },
+   { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low 
latency" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1499,6 +1504,16 @@ static const u32 dp_colorspaces =
  *
  * Drivers can set up these properties by calling
  * drm_mode_create_tv_margin_properties().
+ * power saving policy:
+ * This property is used to set the power saving policy for the connector.
+ * This property is populated with a bitmask of optional requirements set
+ * by the drm master for the drm driver to respect:
+ * - "Require color accuracy": Disable power saving features that will
+ *   affect color fidelity.
+ *   For example: Hardware assisted backlight modulation.
+ * - "Require low latency": Disable power saving features that will
+ *   affect latency.
+ *   For example: Panel self refresh (PSR)
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1963,6 +1978,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_power_saving_policy_property - create power saving policy 
property
+ * @dev: DRM device
+ * @supported_policies: bitmask of supported power saving policies
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies)
+{
+   struct drm_property *power_saving;
+
+   if (dev->mode_config.power_saving_policy)
+   return 0;
+   WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
+
+   power_saving =
+   drm_property_create_bitmask(dev, 0, "power saving policy",
+   drm_power_saving_policy_enum_list,
+   
ARRAY_SIZE(drm_power_saving_policy_enum_list),
+   supported_policies);
+
+   dev->mode_config.power_saving_policy = power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..b0ec2ec48de7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,8 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 8de3c9a5f61b..eefcbf6c5377 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -969,6 +969,11 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @power_saving_policy: bitmask for power saving policy requests.
+*/
+   struct drm_property *power_saving_policy;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 1ca5c7e4

[PATCH v3 1/2] drm: Introduce 'power saving policy' drm property

[Mario Limonciello]

The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.

Acked-by: Leo Li 
Signed-off-by: Mario Limonciello 
---
v2->v3:
* Add tag
---
 drivers/gpu/drm/drm_connector.c | 46 +
 include/drm/drm_connector.h |  2 ++
 include/drm/drm_mode_config.h   |  5 
 include/uapi/drm/drm_mode.h |  7 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..088a5874c7a4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
+   { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color 
accuracy" },
+   { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low 
latency" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1499,6 +1504,16 @@ static const u32 dp_colorspaces =
  *
  * Drivers can set up these properties by calling
  * drm_mode_create_tv_margin_properties().
+ * power saving policy:
+ * This property is used to set the power saving policy for the connector.
+ * This property is populated with a bitmask of optional requirements set
+ * by the drm master for the drm driver to respect:
+ * - "Require color accuracy": Disable power saving features that will
+ *   affect color fidelity.
+ *   For example: Hardware assisted backlight modulation.
+ * - "Require low latency": Disable power saving features that will
+ *   affect latency.
+ *   For example: Panel self refresh (PSR)
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1963,6 +1978,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_power_saving_policy_property - create power saving policy 
property
+ * @dev: DRM device
+ * @supported_policies: bitmask of supported power saving policies
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies)
+{
+   struct drm_property *power_saving;
+
+   if (dev->mode_config.power_saving_policy)
+   return 0;
+   WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
+
+   power_saving =
+   drm_property_create_bitmask(dev, 0, "power saving policy",
+   drm_power_saving_policy_enum_list,
+   
ARRAY_SIZE(drm_power_saving_policy_enum_list),
+   supported_policies);
+
+   dev->mode_config.power_saving_policy = power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..b0ec2ec48de7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,8 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 8de3c9a5f61b..eefcbf6c5377 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -969,6 +969,11 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @power_saving_policy: bitmask for power saving policy requests.
+*/
+   struct drm_property *power_saving_policy;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 1ca5c7e4

[FFmpeg-devel] [PATCH] libswscale/x86/yuv2rgb: Add missing EMMS

[Mario Hros]

Previous rewrite from inline assembly into nasm (commit e934194) missed the 
required EMMS instruction to bring the x87 FPU back into usable state.

Signed-off-by: Mario Hros 
---
 libswscale/x86/yuv_2_rgb.asm | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index e3470fd9ad..7a247797e4 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -353,6 +353,7 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 add imageq, 8 * depth * time_num
 add indexq, 4 * time_num
 js .loop0
+emms
 
 RET
 
-- 
2.39.3 (Apple Git-146)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[regext] Re: regext - New Meeting Session Request for IETF 120

[Mario Loffredo]

Hi Jim,

Il 03/06/2024 20:05, James Galvin ha scritto:

It is a great thing that we have such interest in preparing for extended 
technical discussions at this next REGEXT meeting.

We have until Friday, 7 June, to make adjustments to the request.

Would folks please send suggested agenda items to the list with a desire for 
how much time you’d like to spend talking about them?


Would also like to talk about the future of rdap-jscontact.

If there is no interest from the WG in moving the document forward, have 
no problem to drop it any time but I would like the WG to take a clear 
position.


I speak on my behalf but I imagine that Gavin as co-author agrees on that.

That said, I make some considerations here below:

- yesterday, in his presentation 
<https://regiops.net/sites/default/files/documents/8-ROW13-Simon%20Fernandez-WHOIS%20Right%3F%20An%20Analysis%20of%20WHOIS%20and%20RDAP%20Consistency.pdf> 
at ROW about WHOIS vs RDAP inconsistencies, Simon Fernandez said that 
the jCard format is chaotic and hardly parseable. This is another 
demontration that jCard is considered unfit and we should replace it 
with another one more manageable.


- in light of Andy's feedback on RFC9537 and repeating what I had 
already written in this thread 
<https://mailarchive.ietf.org/arch/msg/regext/I-CG4IwNauiU-6KiNwvaaPU5msQ/>, 
do believe that representing collections in contact data through maps 
instead of arrays (or worse arrays of arrays) would greatly simplify the 
JSONPath expressions used in redaction as the name selector would be 
mostly used in place of index selectors and filters


- the obligation/recommendation included in NIS2 about avoiding contact 
data duplication makes me envisage that in the future we could have 
validated contacts shared among the registries and those contacts will 
be likely identified through universal identifiers. As a result of this, 
a contact data format including a universal identifier could be useful.



Hope it could be helpful to resume the discussion about using JSContact 
or any other well-structured contact data format in RDAP.



Best,

Mario




I know I have my own ideas but I do think it’s important to hear from the 
working group first.

Antoin and I will make an adjustment to the requested time based on what folks 
want to move forward with.

Thanks!

Jim



On 3 Jun 2024, at 10:40, IETF Meeting Session Request Tool wrote:


A new meeting session request has just been submitted by Antoin Verschuren, a
Chair of the REGEXT Working Group.


-
Working Group Name: Registration Protocols Extensions
Area Name: Applications and Real-Time Area
Session Requester: Antoin Verschuren


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 50
Conflicts to Avoid:
  Chair conflict: dnsop dance saag sidrops savnet grow deleg
  Key participant conflict: dispatch secdispatch




Participants who must be present:

Resources Requested:

Special Requests:

-

___
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org


--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
___
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org

Re: [PATCH v2 4/4] backends/hostmem: Report error when memory size is unaligned

[Mario Casquero]

This patch has been successfully tested by QE. After allocating some
hugepages in the host, try to boot up a VM with the memory backed by a
file and the size unaligned, check now the message displayed by QEMU:
qemu-system-x86_64: backend memory size must be multiple of 0x20

Tested-by: Mario Casquero 


On Fri, May 31, 2024 at 9:29 AM Michal Privoznik  wrote:
>
> If memory-backend-{file,ram} has a size that's not aligned to
> underlying page size it is not only wasteful, but also may lead
> to hard to debug behaviour. For instance, in case
> memory-backend-file and hugepages, madvise() and mbind() fail.
> Rightfully so, page is the smallest unit they can work with. And
> even though an error is reported, the root cause it not very
> clear:
>
>   qemu-system-x86_64: Couldn't set property 'dump' on 'memory-backend-file': 
> Invalid argument
>
> After this commit:
>
>   qemu-system-x86_64: backend memory size must be multiple of 0x20
>
> Signed-off-by: Michal Privoznik 
> ---
>  backends/hostmem.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/backends/hostmem.c b/backends/hostmem.c
> index 012a8c190f..5f9c9ea8f5 100644
> --- a/backends/hostmem.c
> +++ b/backends/hostmem.c
> @@ -337,6 +337,7 @@ host_memory_backend_memory_complete(UserCreatable *uc, 
> Error **errp)
>  HostMemoryBackendClass *bc = MEMORY_BACKEND_GET_CLASS(uc);
>  void *ptr;
>  uint64_t sz;
> +size_t pagesize;
>  bool async = !phase_check(PHASE_LATE_BACKENDS_CREATED);
>
>  if (!bc->alloc) {
> @@ -348,6 +349,13 @@ host_memory_backend_memory_complete(UserCreatable *uc, 
> Error **errp)
>
>  ptr = memory_region_get_ram_ptr(>mr);
>  sz = memory_region_size(>mr);
> +pagesize = qemu_ram_pagesize(backend->mr.ram_block);
> +
> +if (!QEMU_IS_ALIGNED(sz, pagesize)) {
> +error_setg(errp, "backend memory size must be multiple of 0x%"
> +   PRIx64, pagesize);
> +return;
> +}
>
>  if (backend->merge &&
>  qemu_madvise(ptr, sz, QEMU_MADV_MERGEABLE)) {
> --
> 2.44.1
>
>

Re: [apache/incubator-teaclave] Issues with keys (Issue #727)

[Mario López]

Closed #727 as not planned.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-teaclave/issues/727#event-13033225200
You are receiving this because you are subscribed to this thread.

Message ID: 

Re: [Metamath] Metamath proof visualizer with graphs

[Mario Carneiro]

This is amazing and super awesome, and I will be using it in all my talks
from now on. :) It makes me more excited for getting that site rewrite
project moving forward...

On Tue, Jun 4, 2024 at 12:27 AM Matthias Vogt 
wrote:

> Hi everyone,
> I wrote a cool visualizer for metamath proofs :3
>
> [image: Screenshot from 2024-06-03 20-54-43.png]
> It can...
>
>- Show the proof steps as an interactive graph
>- Show the proof as interactive nested proof blocks, from conclusion
>to premises
>- Summarize proofs and explain proof steps (I only hand-wrote
>explanation-functions for a few theorems, e.g. "by transitivity..." below)
>- Hide proof steps that you consider trivial, i.e. have a theorem
>number less than x
>
> You can view it (please use desktop) at https://vo.gt/mm/mpeuni/2p2e4 or
> add it as a tampermonkey extension . You
> can replace "2p2e4" in the URL with any theorem you like.
>
> This is at the moment a super slow and hacky proof of concept and there
> are likely many bugs. The site above mirrors metamath.tirix.org (if it is
> not OK that I am mirroring math.tirix.org, please tell me and I will of
> course take down this demo site. It is not indexed by search engines or
> linked anywhere except here.). It also makes lots of requests to
> metamath.org to get the theorem numbers. Moreover, it runs the
> expln.github.io  react
> code to get the substitutions that show us how theorems are used in proof
> steps. The code is basically an unmaintainable fever dream :p If there is
> interest, I might rewrite it in react at some point in the future. But I
> hope you like it anyway :)
>
> The basic idea for summarizing proofs is that smaller theorem numbers
> correspond to logic glue, so we can just not mention these theorems
> explicitly in the proof. Instead, when we have a non-trivial step, we just
> silently add the application of the trivial theorem to the resulting
> expression. The threshold for what is trivial customizable with the slider.
> Swallowing logic glue helps for readability, but still, in reality, I think
> what part of a proof is verbose is more of a stylistic decision by the
> author.
>
> What would make the visualizer even better is if there was a way to get
> LaTeX or Unicode output for the terms in the substitutions. But I don't
> know how to do this. If expln.github.io
>  had LaTeX/Unicode
> support, that could be used for the visualizer for example.
>
> Best
> Matthias
>
> --
> You received this message because you are subscribed to the Google Groups
> "Metamath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to metamath+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/metamath/6fd3b538-ac91-431f-a476-9d79e4754b14n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Metamath" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to metamath+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/metamath/CAFXXJStDO%2BphLRPGV63VGHzrc18vjej-72y2sfME8_QEMerCUw%40mail.gmail.com.

Re: [Chicken-announce] [ANN] CHICKEN 5.4.0 release candidate available

[Mario Domenech Goulart]

Hi,

On Fri, 31 May 2024 10:08:42 +0200 Peter Bex  wrote:

> We are happy to announce the first release candidate of the upcoming
> CHICKEN 5.4.0.

I've tested 5.4.0rc1 on the systems below (all x86-64).  Build,
installation, "make check" of CHICKEN and installation + tests of
pastiche work.

OS C CompilerLibC
--+-+---
Debian 12.5gcc   glibc
Debian 12.5clang glibc
Debian 12.5tcc   glibc
Alpine 3.19.1  gcc   musl
Alpine 3.19.1  clang musl
Alpine 3.20.0  gcc   musl
Alpine 3.20.0  clang musl

# Commands executed

$ make PREFIX=... C_COMPILER=... -j$(nproc) all
$ make PREFIX=... C_COMPILER=... install
$ make PREFIX=... C_COMPILER=... check
$ $PREFIX/bin/chicken-install -test pastiche

$(nproc) was 4, 8 or 12, depending on the system.


# Alpine 3.19.1

$ gcc --version
gcc (Alpine 13.2.1_git20231014) 13.2.1 20231014
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Alpine clang version 17.0.5
Target: x86_64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang17/x86_64-alpine-linux-musl.cfg

$ /lib/ld-musl-x86_64.so.1 --version
musl libc (x86_64)
Version 1.2.4_git20230717
Dynamic Program Loader
Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname [args]


# Alpine 3.20.0

$ gcc --version
gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Alpine clang version 17.0.6
Target: x86_64-alpine-linux-musl
Thread model: posix
InstalledDir: /usr/bin
Configuration file: /etc/clang17/x86_64-alpine-linux-musl.cfg

$ /lib/ld-musl-x86_64.so.1 --version
musl libc (x86_64)
Version 1.2.5
Dynamic Program Loader
Usage: /lib/ld-musl-x86_64.so.1 [options] [--] pathname [args]


# Debian 12.5

$ gcc --version
gcc (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ clang --version
Debian clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ tcc -version
tcc version 0.9.27 (x86_64 Linux)

(tcc has been patched with VSTACK_SIZE = 1024)

$ /lib/ld-linux.so.2 --version
ld.so (Debian GLIBC 2.36-9+deb12u7) stable release version 2.36.
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.


All the best.
Mario
-- 
http://parenteses.org/mario

BUG in the Chromium port : pkg-static: py311-build-1.2.1 conflicts with py39-build-1.2.1.

[Mario Marietto]

 Hello.

I'm trying to compile Chromium from the ports on my system (14.0 p6 with
latest packages),but I found a bug.

[root@marietto /usr/ports/www/chromium]==> make
.
Link: @bin/pyproject-build --> bin/pyproject-build-3.11
> Compressing man pages (compress-man)
===>  Installing for py311-build-1.2.1
===>  Checking if py311-build is already installed
===>   Registering installation for py311-build-1.2.1 as automatic
Installing py311-build-1.2.1...

pkg-static: py311-build-1.2.1 conflicts with py39-build-1.2.1
(installs files into the same place).
Problematic file: /usr/local/bin/pyproject-build

*** Error code 1

Stop.
make[6]: stopped in /usr/ports/devel/py-build
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/devel/py-wheel
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/textproc/py-markupsafe
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/chromium
*** Error code 1

Stop.
make: stopped in /usr/ports/www/chromium

[root@marietto /usr/ports/www/chromium]==> mv
/usr/local/bin/pyproject-build /usr/local/bin/pyproject-build_

[root@marietto /usr/ports/www/chromium]==> make

===>   chromium-125.0.6422.112 depends on executable: bash - found
===>   chromium-125.0.6422.112 depends on package: py311-Jinja2>0 - not found
===>  Staging for py311-Jinja2-3.1.3
===>   py311-Jinja2-3.1.3 depends on package: py311-markupsafe>=2.0.0
- not found
===>   py311-markupsafe-2.1.5_1 depends on package: py311-setuptools>=0 - found
===>   py311-markupsafe-2.1.5_1 depends on package: py311-wheel>=0 - not found
===>   py311-wheel-0.43.0 depends on package: py311-flit-core>=3.8 - found
===>   py311-wheel-0.43.0 depends on file: /usr/local/bin/python3.11 - found
===>   py311-wheel-0.43.0 depends on package: py311-build>=0 - not found
===>  Installing for py311-build-1.2.1
===>  Checking if py311-build is already installed
===>   Registering installation for py311-build-1.2.1 as automatic
Installing py311-build-1.2.1...
pkg-static: py311-build-1.2.1 conflicts with py39-build-1.2.1
(installs files into the same place).  Problematic file:
/usr/local/bin/pyproject-build
*** Error code 1

Stop.
make[6]: stopped in /usr/ports/devel/py-build
*** Error code 1

Stop.
make[5]: stopped in /usr/ports/devel/py-wheel
*** Error code 1

Stop.
make[4]: stopped in /usr/ports/textproc/py-markupsafe
*** Error code 1

Stop.
make[3]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[2]: stopped in /usr/ports/devel/py-Jinja2
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/www/chromium
*** Error code 1

Stop.
make: stopped in /usr/ports/www/chromium

Any idea about how to fix it ?

-- 
Mario.

RE: How can I get an AI Chatbot to interpret a nine page PDF?

[Mario Eiland]

HI Keith,
This might help.

Here is a YouTube video tutorial for a Chrome Image to Text for ChatGPT 
extension.
https://www.youtube.com/watch?v=zob0us4bPc8


-Original Message-
From: viphone@googlegroups.com  On Behalf Of Keith 
Kramlinger
Sent: Saturday, June 1, 2024 2:40 PM
To: viphone@googlegroups.com
Subject: How can I get an AI Chatbot to interpret a nine page PDF?

Hi,
I have a nine page PDF composed of both text and images. I would like to get an 
AI chat bot to describe this to me.

I cannot figure out how to get the complete PDF uploaded to a chatbot in order 
to do this. Is it possible, or just too long?

I would appreciate any guidance on the viability of this, and if possible, 
Specific guidance on how to achieve it.

Thanks in advance. Keith

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/DM5PR02MB3179EE6F080BC121766C6DE1DEFD2%40DM5PR02MB3179.namprd02.prod.outlook.com.

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/012001dab46f%24759b1c00%2460d15400%24%40gmail.com.

[Spectacle] [Bug 487596] Screenshot region selection broken with fractional scaling on multi-monitor setups (X11)

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487596

Mario Ebenhofer  changed:

   What|Removed |Added

   Version Fixed In||24.02.0

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 462860] Rectangle capture modes have wrong GUI sizing and positioning with fractional scaling

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=462860

Mario Ebenhofer  changed:

   What|Removed |Added

 CC||m...@fsfe.org

--- Comment #65 from Mario Ebenhofer  ---
*** Bug 487596 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 487596] Screenshot region selection broken with fractional scaling on multi-monitor setups (X11)

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487596

Mario Ebenhofer  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|REPORTED|RESOLVED

--- Comment #4 from Mario Ebenhofer  ---


*** This bug has been marked as a duplicate of bug 462860 ***

-- 
You are receiving this mail because:
You are watching all bug changes.

[Spectacle] [Bug 487596] Screenshot region selection broken with fractional scaling on multi-monitor setups (X11)

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487596

Mario Ebenhofer  changed:

   What|Removed |Added

 CC||mano...@mailbox.org

--- Comment #3 from Mario Ebenhofer  ---
I've had this issue on an older version of Spectacle, too. It should be fixed
in a later version (apparently 24.02.0).
See https://bugs.kde.org/show_bug.cgi?id=462860

-- 
You are receiving this mail because:
You are watching all bug changes.

RE: Heading Level Access In Safari Browser

[Mario Eiland]

Use the rotor while in the Safari app and look for headings. Once you hear 
headings then flick down with one finger and that should take you from heading 
to heading. To go up flick up.
If you can't find the heading option in the rotor then you must add it in the 
VoiceOver rotor settings.

Good luck!

-Original Message-
From: viphone@googlegroups.com  On Behalf Of Ron 
Canazzi
Sent: Friday, May 31, 2024 8:42 AM
To: ViPhone List 
Subject: Heading Level Access In Safari Browser

Hi Group,

I finally was able to change some settings in Safari Browser on the iPhone to 
get it to display HTML files that are stored locally on the iPhone.  I  created 
my modified Dice Football Game Play Sheet by using headings to more quickly 
navigate from play list to play list.  I have the lists separated into running 
plays, kicking plays, passing plays and conversions at level one and the 
various list of items such as short pass, long pass and screen pass for the 
passing plays and the running plays such as left end run, right tackle play and 
reverse at heading level two.

Is there any way to navigate by heading levels using a quick number scheme such 
as is done on Windows desktops with quick key number navigation such as number 
one for heading level one and number two for heading level two on the iPhone?

Thanks for any help.

--
Signature:
For a nation to admit it has done grievous wrongs and will strive to correct 
them for the betterment of all is no vice; For a nation to claim it has always 
been great, needs no improvement  and to cling to its past achievements is no 
virtue!

--
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
---
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/7a3d2c9c-6deb-8621-6d2a-105199764add%40roadrunner.com.

-- 
The following information is important for all members of the V iPhone list.

If you have any questions or concerns about the running of this list, or if you 
feel that a member's post is inappropriate, please contact the owners or 
moderators directly rather than posting on the list itself.

Your V iPhone list moderator is Mark Taylor.  Mark can be reached at:  
mk...@ucla.edu.  Your list owner is Cara Quinn - you can reach Cara at 
caraqu...@caraquinn.com

The archives for this list can be searched at:
http://www.mail-archive.com/viphone@googlegroups.com/
--- 
You received this message because you are subscribed to the Google Groups 
"VIPhone" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to viphone+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/viphone/07b201dab376%24268febd0%2473afc370%24%40gmail.com.

Re: [RFC] virtio testing framework

[Mario Marietto]

I mean,what's the purpose of using "NuttX RTOS on RV in a web browser using
TinyEMU + VirtIO" ?

On Fri, May 31, 2024 at 6:07 AM Emil Tsalapatis 
wrote:

> Not sure about the followup, but the patch I describe in the original post
> allows us to write and run tests for virtio drivers inside a VM. I
> originally wrote this because we have tests for the virtiofs paravirt
> device where we need to run both the paravirt driver and the device
> emulation in the same machine. The virtio stack is not designed for this -
> it expects the virtio driver to be running in the guest, and device
> emulation to be running in the host. This patchset introduces a way to
> emulate a virtio device in the guest for the purpose of running these
> virtiofs tests. The links in the original email describe the design in more
> detail, but just to reiterate, the code in this patch makes no functional
> changes to existing code.
>
> --Emil
>
> On Thu, May 30, 2024 at 6:19 PM Mario Marietto 
> wrote:
>
>> Can someone explain to me what the purpose of what you are talking about
>> ?
>>
>>
>> On Thu, May 30, 2024 at 10:38 PM Tomek CEDRO  wrote:
>>
>>> Awesome!! Congrats :-)
>>>
>>> Here is some example of running NuttX RTOS on RV in a web browser using
>>> TinyEMU + VirtIO :-)
>>>
>>> https://github.com/lupyuen/nuttx-tinyemu
>>>
>>> --
>>> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>>>
>>> On Thu, May 30, 2024, 22:16 Emil Tsalapatis 
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> while developing a virtiofs kernel driver I have written a debug
>>>> virtio transport to test virtio drivers inside a VM without requiring
>>>> nested virtualization or support from the host. The transport allows
>>>> paravirt devices to be emulated in local userspace instead of a host, so we
>>>> can create paravirt devices and test them as necessary. For virtiofs in
>>>> particular, it allows us to reuse the existing FUSE tests since we can now
>>>> run both the virtiofs driver and the FUSE server (which is normally in the
>>>> host) in a single machine.
>>>>
>>>> I have uploaded the WIP code [here <https://reviews.freebsd.org/D45370>],
>>>> and an overview of the design [here
>>>> <https://gist.github.com/etsal/4280b6f16c1815d64ffda7ecce0b66f5>]. The
>>>> patch has a ways to go, and currently only supports virtio-blk device
>>>> emulation as a PoC, but feedback is welcome and appreciated. Please also
>>>> let me know if there is interest in using this for testing other virtio
>>>> devices apart from virtiofs.
>>>>
>>>> --Emil
>>>>
>>>
>>
>> --
>> Mario.
>>
>

-- 
Mario.

Re: [Flying-squirrel-members] May 28 meeting notes

[Mario Savastano]

Does anyone have contact info for Lamar, the person doing Mental Wealth
open mike nights the third Thursday of every month? I can't book him
upstairs in June or July due to other groups rehearsing. It's clear from
August 15 on (or he can do Weds in June & July).. I told him I'd take care
of it, and I'd rather not wait until the next Squirrel meeting to
address it. If I can get his info, I'll get in touch with him and work it
out.

Mario

On Tue, May 28, 2024 at 8:31 PM Al Brundage  wrote:

> Flying Squirrel General Meeting May 28 2024
>
> EVENTS
>
> July 6 whole building Art and Cipher Event
> Can coexist with Food Not Bombs
> Approved
>
> July 25 Poetry reading 7-9pm up or downstairs
> approved
>
> August 22 Poetry reading with Pathway Poets 7-9pm up or downstairs
> approved
>
> August 2 3 and 4 Fundraising Weekend
> 50-50 split with Squirrel Gabrielle can bottomline
> Fri music show 7-10
> Sat Music and Vendors upstairs/downstairs all day whole building
> only other event is FNB – can coexist
> Need to find out if CHNA wants to reserve upstairs on Sundays
>
> Community Garage Sale
> July 6 can coexist with other FAC event
> August 3 12-5 whole building
> Sept 7 12-5 whole building
> Oct 5
> Nov 2
> Dec 7
> approved
>
> August 24 fashion show (already scheduled)
> August 25 need to find about Corn Hill
>
> Sept 15 Community Arts and Cypher
> whole building 1-6pm
> approved
>
> Sept 21 full day both floors
> RIT music fest fundraiser for Free Art Collective
> approved
>
> Oct 27 Halloween Art Market
> both floors 1-6
> approved
>
> Music Show (Laura) July 7
> already approved
>
> Music Show (Laura) Oct 18
> approved
>
> Concert/Performances
> No date given, no details, Chris S will follow up
>
> Poetry Nights:
> July 25
> August 22
>
> July 27 music show (Laura)
> approved (replaces Worgofest which has been moved)
>
> Art Jam June 7 has been cancelled
> Laura's music event that day is still happening
> should already be on calendar
>
> July 6 music show (Laura)
> approved
>
> July 7 music show  Hormone from Baltimore
> Chris S will contact and confirm
>
> August 31 music show (Laura)
> approved
> Open Mic (Lamar)
> will come back with series of dates
> 3rd Thursday June - December 6:30-8:30
> Mario will set up
> approved
>
> Clarissa St Reunion
> Need to block off Friday Night before event for setup
> Ricardo is handling
>
> RAGS (Rochester Anarchist Group Sewing)
> Sundays 11am-2pm downstairs or upstairs
> conflicts with NAC group
> could meet upstairs
> approved
>
> VENMO
> Mario has information to set up account
> Gabrielle still owes $36 from last show
> will coordinate with Mario once account is set up
> ___
> Flying-squirrel-members mailing list
> Flying-squirrel-members@lists.rocus.org
> https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members
>
> To unsubscribe, send an email to:
> flying-squirrel-members-unsubscr...@lists.rocus.org
> (The subject and body of the email don't matter)
>
___
Flying-squirrel-members mailing list
Flying-squirrel-members@lists.rocus.org
https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members

To unsubscribe, send an email to:
flying-squirrel-members-unsubscr...@lists.rocus.org
(The subject and body of the email don't matter)

Re: [RFC] virtio testing framework

[Mario Marietto]

Can someone explain to me what the purpose of what you are talking about ?


On Thu, May 30, 2024 at 10:38 PM Tomek CEDRO  wrote:

> Awesome!! Congrats :-)
>
> Here is some example of running NuttX RTOS on RV in a web browser using
> TinyEMU + VirtIO :-)
>
> https://github.com/lupyuen/nuttx-tinyemu
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
>
> On Thu, May 30, 2024, 22:16 Emil Tsalapatis  wrote:
>
>> Hi everyone,
>>
>> while developing a virtiofs kernel driver I have written a debug
>> virtio transport to test virtio drivers inside a VM without requiring
>> nested virtualization or support from the host. The transport allows
>> paravirt devices to be emulated in local userspace instead of a host, so we
>> can create paravirt devices and test them as necessary. For virtiofs in
>> particular, it allows us to reuse the existing FUSE tests since we can now
>> run both the virtiofs driver and the FUSE server (which is normally in the
>> host) in a single machine.
>>
>> I have uploaded the WIP code [here <https://reviews.freebsd.org/D45370>],
>> and an overview of the design [here
>> <https://gist.github.com/etsal/4280b6f16c1815d64ffda7ecce0b66f5>]. The
>> patch has a ways to go, and currently only supports virtio-blk device
>> emulation as a PoC, but feedback is welcome and appreciated. Please also
>> let me know if there is interest in using this for testing other virtio
>> devices apart from virtiofs.
>>
>> --Emil
>>
>

-- 
Mario.

Re: HAXM + NVMM is doable ?

[Mario Marietto]

At the moment , can NVMM be used in conjunction with QEMU as an
accelerator ?

On Thu, May 30, 2024 at 3:41 PM James Cave  wrote:

> Hi, Mario,
>
> Intel discontinued development of HAXM last year because all the
> major operating systems include hypervisor backends of their own.
> As a result, QEMU removed the HAXM backend in version 8.2.
>
> Looking at pkgsrc.se, I see that the CVS log for the emulators/haxm
> package mentions a quick fix to get it to build on an old version
> of -current, but also mentions that "this package seems to have
> other potential issues." I wouldn't expect it to work well with
> NetBSD 10.
>
> ~ James
>


-- 
Mario.

Re: Jenkins integration

[Mario Izaguirre]

Hi i view at github.com/IBM/zvm_ansible few modules about.


Regarás,



Mario Izaguirre
Barcelona, Spain


El El mar, 28 may 2024 a las 15:02, Philip Tully 
escribió:

> Does anyone know if there is any integration with zVM for Jenkins or
> Github ?
>
> Phil
>
> --
> For LINUX-390 subscribe / signoff / archive access instructions,
> send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
> visit
> http://www2.marist.edu/htbin/wlvindex?LINUX-390
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Fwd: HAXM + NVMM is doable ?

[Mario Marietto]

Sorry,I meant : At the moment , can HAXM be used in conjunction with QEMU
as an accelerator ? Thanks.

-- Forwarded message -
From: Mario Marietto 
Date: Thu, May 30, 2024 at 2:12 PM
Subject: HAXM + NVMM is doable ?
To: Netbsd-Users-List 


Hello NetBSD developers and users.

What's the current state of the HAXM hypervisor ? Is it stable and good ?
Can it be used in conjunction with NVMM ?

Thanks.

-- 
Mario.


-- 
Mario.

HAXM + NVMM is doable ?

[Mario Marietto]

Hello NetBSD developers and users.

What's the current state of the HAXM hypervisor ? Is it stable and good ?
Can it be used in conjunction with NVMM ?

Thanks.

-- 
Mario.

[Discover] [Bug 487442] Discover crashes when tiling and then resizing the window to a very small size.

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487442

Mario Ebenhofer  changed:

   What|Removed |Added

 Resolution|WAITINGFORINFO  |---
 Status|NEEDSINFO   |REPORTED

-- 
You are receiving this mail because:
You are watching all bug changes.

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Limonciello, Mario]

Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
someone needs this to work on non-ACPI system they get to figure out
how to abstract it better. acpi_lid_open() does seem to return != 0
when ACPI is not supported, so at least it would err on the side
of enabling everything.


Thanks. I was going to comment, but you got it first. I think a proper
implementation should check for SW_LID input device instead of simply
using acpi_lid_open(). This will handle the issue for other,
non-ACPI-based laptops.



Can you suggest how this would actually work?  AFAICT the only way to 
discover if input devices support SW_LID would be to iterate all the 
input devices in the kernel and look for whether ->swbit has SW_LID set.


This then turns into a dependency problem of whether any myriad of 
drivers have started to report SW_LID.  It's also a state machine 
problem because other drivers can be unloaded at will.


And then what do you if more than one sets SW_LID?

IOW - a lot of complexity for a non-ACPI system.  Does such a problem 
exist in non-ACPI systems?

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Limonciello, Mario]

Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
someone needs this to work on non-ACPI system they get to figure out
how to abstract it better. acpi_lid_open() does seem to return != 0
when ACPI is not supported, so at least it would err on the side
of enabling everything.


Thanks. I was going to comment, but you got it first. I think a proper
implementation should check for SW_LID input device instead of simply
using acpi_lid_open(). This will handle the issue for other,
non-ACPI-based laptops.



Can you suggest how this would actually work?  AFAICT the only way to 
discover if input devices support SW_LID would be to iterate all the 
input devices in the kernel and look for whether ->swbit has SW_LID set.


This then turns into a dependency problem of whether any myriad of 
drivers have started to report SW_LID.  It's also a state machine 
problem because other drivers can be unloaded at will.


And then what do you if more than one sets SW_LID?

IOW - a lot of complexity for a non-ACPI system.  Does such a problem 
exist in non-ACPI systems?

Re: new egg: poule - manage a pool of worker processes

[Mario Domenech Goulart]

On Tue, 28 May 2024 12:39:13 + Pietro Cerutti  wrote:

> this egg implements a manager for a pool of worker processes.
>
> Code: https://code.ptrcrt.ch/poule/
> Docs: http://wiki.call-cc.org/eggref/5/poule

Thanks, Pietro!  Your egg has been added to the coop.

All the best.
Mario
-- 
http://parenteses.org/mario

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If you don't hook into some lid notify event how is one supposed to get
the display back to life after opening the lid?


I guess in my mind it's a tangential to the "initial modeset".  The DRM
master can issue a modeset to enable the combination as desired.


This code is run whenever there's a hotplug/etc. Not sure why you're
only thinking about the initial modeset.


Got it; so in that case adding a notification chain for lid events to 
run it again should do the trick.






When I tested I did confirm that with mutter such an event is received
and it does the modeset to enable the eDP when lid is opened.


This code isn't relevant when you have a userspace drm master
calling the shots.


Right.





Let me ask this - what happens if no DRM master running and you hotplug
a DP cable?  Does a "new" clone configuration get done?


Yes, this code reprobes the displays and comes up with a new
config to suit the new situation.


Got it; in this case you're right we should have some notification 
chain.  Do you think it should be in the initial patch or a follow up?




The other potential issue here is whether acpi_lid_open() is actually
trustworthy. Some kms drivers have/had some lid handling in their own
code, and I'm pretty sure those have often needed quirks/modparams
to actually do sensible things on certain machines.

FWIW I ripped out all the lid crap from i915 long ago since it was
half backed, mostly broken, and ugly, and I'm not looking to add it
back there. But I do think handling that in drm_client does seem
somewhat sane, as that should more or less match what userspace
clients would do. Just a question of how bad the quirk situation
will get...



If the lid reporting is wrong it's not just drm_client that would 
falter.  There are other parts of the kernel that rely upon 
acpi_lid_open() being accurate and IMO it would be best to put any 
quirks to the effect in drivers/acpi/button.c.


If it can't be relied upon then it's best to just report -EINVAL or -ENODEV.



Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
someone needs this to work on non-ACPI system they get to figure out
how to abstract it better. acpi_lid_open() does seem to return != 0
when ACPI is not supported, so at least it would err on the side
of enabling everything.



Yeah acpi_lid_open() seemed fine to me specifically because non ACPI 
hardcodes to open.

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If you don't hook into some lid notify event how is one supposed to get
the display back to life after opening the lid?


I guess in my mind it's a tangential to the "initial modeset".  The DRM
master can issue a modeset to enable the combination as desired.


This code is run whenever there's a hotplug/etc. Not sure why you're
only thinking about the initial modeset.


Got it; so in that case adding a notification chain for lid events to 
run it again should do the trick.






When I tested I did confirm that with mutter such an event is received
and it does the modeset to enable the eDP when lid is opened.


This code isn't relevant when you have a userspace drm master
calling the shots.


Right.





Let me ask this - what happens if no DRM master running and you hotplug
a DP cable?  Does a "new" clone configuration get done?


Yes, this code reprobes the displays and comes up with a new
config to suit the new situation.


Got it; in this case you're right we should have some notification 
chain.  Do you think it should be in the initial patch or a follow up?




The other potential issue here is whether acpi_lid_open() is actually
trustworthy. Some kms drivers have/had some lid handling in their own
code, and I'm pretty sure those have often needed quirks/modparams
to actually do sensible things on certain machines.

FWIW I ripped out all the lid crap from i915 long ago since it was
half backed, mostly broken, and ugly, and I'm not looking to add it
back there. But I do think handling that in drm_client does seem
somewhat sane, as that should more or less match what userspace
clients would do. Just a question of how bad the quirk situation
will get...



If the lid reporting is wrong it's not just drm_client that would 
falter.  There are other parts of the kernel that rely upon 
acpi_lid_open() being accurate and IMO it would be best to put any 
quirks to the effect in drivers/acpi/button.c.


If it can't be relied upon then it's best to just report -EINVAL or -ENODEV.



Also a direct acpi_lid_open() call seems a bit iffy. But I guess if
someone needs this to work on non-ACPI system they get to figure out
how to abstract it better. acpi_lid_open() does seem to return != 0
when ACPI is not supported, so at least it would err on the side
of enabling everything.



Yeah acpi_lid_open() seemed fine to me specifically because non ACPI 
hardcodes to open.

[ccp4bb] Postdoc position available at LNBR/CNPEM

[Mario Tyago Murakami]

Postdoctoral position available in carbohydrate enzymology and structural 
biology
We are looking for candidates who are interested in exploring the microbial 
dark matter from Brazilian mega biodiversity aiming at elucidating novel 
mechanisms involved in carbohydrate breakdown and modification using an 
interdisciplinary approach including integrated omics, carbohydrate enzymology, 
site-directed mutagenesis, X-ray crystallography, Cryo-EM, mass spectrometry 
and computational biology.
Application deadline June 21, 2024; Expected starting date August 1st, 2024.

Mário Murakami
mario.murak...@lnbr.cnpem.br



Mário T. Murakami

Scientific Director

Brazilian Biorenewables National Laboratory (LNBR)

National Center for Research in Energy and Materials (CNPEM)

Rua Giuseppe Máximo Scolfaro, 10.000 – Campinas, São Paulo, Brasil. CEP: 
13083-100

(19) 3518-3198 | (19) 99654 3909 | 
mario.murak...@lnbr.cnpem.br

www.lnbr.cnpem.br / 
www.cnpem.br




Aviso Legal: Esta mensagem e seus anexos podem conter informações confidenciais 
e/ou de uso restrito. Observe atentamente seu conteúdo e considere eventual 
consulta ao remetente antes de copiá-la, divulgá-la ou distribuí-la. Se você 
recebeu esta mensagem por engano, por favor avise o remetente e apague-a 
imediatamente.

Disclaimer: This email and its attachments may contain confidential and/or 
privileged information. Observe its content carefully and consider possible 
querying to the sender before copying, disclosing or distributing it. If you 
have received this email by mistake, please notify the sender and delete it 
immediately.



To unsubscribe from the CCP4BB list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/WA-JISC.exe?SUBED1=CCP4BB=1

This message was issued to members of www.jiscmail.ac.uk/CCP4BB, a mailing list 
hosted by www.jiscmail.ac.uk, terms & conditions are available at 
https://www.jiscmail.ac.uk/policyandsecurity/

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

On 5/29/2024 09:14, Ville Syrjälä wrote:

On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
Cc: hughsi...@gmail.com
v1->v2:
  * Match LVDS as well
---
  drivers/gpu/drm/drm_client_modeset.c | 30 
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
   */
  
  #include "drm/drm_modeset_lock.h"

+#include 
  #include 
  #include 
  #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
  }
  
+static void drm_client_match_edp_lid(struct drm_device *dev,

+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}


If you don't hook into some lid notify event how is one supposed to get
the display back to life after opening the lid?


I guess in my mind it's a tangential to the "initial modeset".  The DRM 
master can issue a modeset to enable the combination as desired.


When I tested I did confirm that with mutter such an event is received 
and it does the modeset to enable the eDP when lid is opened.


Let me ask this - what happens if no DRM master running and you hotplug 
a DP cable?  Does a "new" clone configuration get done?



+
  static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
  
+		drm_client_match_edp_lid(dev, connectors, connector_count, enabled);

if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
--
2.43.0

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

On 5/29/2024 09:14, Ville Syrjälä wrote:

On Tue, May 28, 2024 at 04:03:19PM -0500, Mario Limonciello wrote:

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
Cc: hughsi...@gmail.com
v1->v2:
  * Match LVDS as well
---
  drivers/gpu/drm/drm_client_modeset.c | 30 
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
   */
  
  #include "drm/drm_modeset_lock.h"

+#include 
  #include 
  #include 
  #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
  }
  
+static void drm_client_match_edp_lid(struct drm_device *dev,

+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}


If you don't hook into some lid notify event how is one supposed to get
the display back to life after opening the lid?


I guess in my mind it's a tangential to the "initial modeset".  The DRM 
master can issue a modeset to enable the combination as desired.


When I tested I did confirm that with mutter such an event is received 
and it does the modeset to enable the eDP when lid is opened.


Let me ask this - what happens if no DRM master running and you hotplug 
a DP cable?  Does a "new" clone configuration get done?



+
  static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
  
+		drm_client_match_edp_lid(dev, connectors, connector_count, enabled);

if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
--
2.43.0

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

On 5/29/2024 08:55, Alex Deucher wrote:

On Wed, May 29, 2024 at 9:51 AM Jani Nikula  wrote:


On Wed, 29 May 2024, Alex Deucher  wrote:

On Tue, May 28, 2024 at 5:03 PM Mario Limonciello
 wrote:


If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 


Reviewed-by: Alex Deucher 

Do you have drm-misc access or do you need someone to apply this for you?


I've bounced this to intel-gfx and intel-xe lists to get CI testing. I'd
appreciate holding off on merging until we have results.


Sure.


Thanks for the review and pushing it to CI testing infra.

I don't have any drm-misc access so if everything looks good then one of 
you guys please merge it for me.


Thanks!



Alex



Thanks,
Jani.



Alex


---
Cc: hughsi...@gmail.com
v1->v2:
  * Match LVDS as well
---
  drivers/gpu/drm/drm_client_modeset.c | 30 
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
   */

  #include "drm/drm_modeset_lock.h"
+#include 
  #include 
  #include 
  #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
 enabled[i] = drm_connector_enabled(connectors[i], false);
  }

+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
  static bool drm_client_target_cloned(struct drm_device *dev,
  struct drm_connector **connectors,
  unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
 memset(crtcs, 0, connector_count * sizeof(*crtcs));
 memset(offsets, 0, connector_count * sizeof(*offsets));

+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
 if (!drm_client_target_cloned(dev, connectors, 
connector_count, modes,
   offsets, enabled, width, height) 
&&
 !drm_client_target_preferred(dev, connectors, 
connector_count, modes,
--
2.43.0



--
Jani Nikula, Intel

Re: [PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

On 5/29/2024 08:55, Alex Deucher wrote:

On Wed, May 29, 2024 at 9:51 AM Jani Nikula  wrote:


On Wed, 29 May 2024, Alex Deucher  wrote:

On Tue, May 28, 2024 at 5:03 PM Mario Limonciello
 wrote:


If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 


Reviewed-by: Alex Deucher 

Do you have drm-misc access or do you need someone to apply this for you?


I've bounced this to intel-gfx and intel-xe lists to get CI testing. I'd
appreciate holding off on merging until we have results.


Sure.


Thanks for the review and pushing it to CI testing infra.

I don't have any drm-misc access so if everything looks good then one of 
you guys please merge it for me.


Thanks!



Alex



Thanks,
Jani.



Alex


---
Cc: hughsi...@gmail.com
v1->v2:
  * Match LVDS as well
---
  drivers/gpu/drm/drm_client_modeset.c | 30 
  1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
   */

  #include "drm/drm_modeset_lock.h"
+#include 
  #include 
  #include 
  #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
 enabled[i] = drm_connector_enabled(connectors[i], false);
  }

+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
  static bool drm_client_target_cloned(struct drm_device *dev,
  struct drm_connector **connectors,
  unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
 memset(crtcs, 0, connector_count * sizeof(*crtcs));
 memset(offsets, 0, connector_count * sizeof(*offsets));

+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
 if (!drm_client_target_cloned(dev, connectors, 
connector_count, modes,
   offsets, enabled, width, height) 
&&
 !drm_client_target_preferred(dev, connectors, 
connector_count, modes,
--
2.43.0



--
Jani Nikula, Intel

[PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
Cc: hughsi...@gmail.com
v1->v2:
 * Match LVDS as well
---
 drivers/gpu/drm/drm_client_modeset.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

[PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
Cc: hughsi...@gmail.com
v1->v2:
 * Match LVDS as well
---
 drivers/gpu/drm/drm_client_modeset.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

[PATCH v2] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
Cc: hughsi...@gmail.com
v1->v2:
 * Match LVDS as well
---
 drivers/gpu/drm/drm_client_modeset.c | 30 
 1 file changed, 30 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..0b0411086e76 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,34 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   switch (connector->connector_type) {
+   case DRM_MODE_CONNECTOR_LVDS:
+   case DRM_MODE_CONNECTOR_eDP:
+   if (!enabled[i])
+   continue;
+   break;
+   default:
+   continue;
+   }
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +873,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

Re: Refine the firmware-updates exception

[Mario Limonciello]

Ping?


From: Mario Limonciello 
Sent: Wednesday, May 1, 2024 10:32:49 AM
To: Robie Basak ; Mario Limonciello 
Cc: ubuntu-release@lists.ubuntu.com ; Richard 
Hughes 
Subject: Re: Refine the firmware-updates exception

Robie,

My apologies; my email didn't get a response a while and I was on leave
a while when your response came back and I totally missed it.

Your comment on bug 1979963 prompted me to find it though!

On 3/7/24 08:00, Robie Basak wrote:
> Hi Mario,
>
> Thank you for caring for the fwupd package in Ubuntu!
>

Sure.

> One adminsitrative question: fwupd is in main and the Foundations team
> are committed to looking after it. Is your proposal made on behalf of or
> in coordination with the Foundations team? If not, what's the Foundation
> team's view on your proposal?

I am part of ~ubuntu-foundations-team, but admittedly I have not
conferred closely with other members.

I would invite discussion on any opposing views from other members.

>
> On Sun, Feb 18, 2024 at 12:11:48AM -0600, Mario Limonciello wrote:
>> Considering all of that, I wanted to discuss with the release team to
>> modify the exception used for the firmware updating stack to allow
>> migrations from one stable branch to another; especially considering EOL
>> dates.
>> I've drafted an updated proposal in this wiki page and aligned it
>> directionally upstream:
>> https://wiki.ubuntu.com/firmware-updates-2.0
>>
>> Can the release team please review and consider this?  If approved we can
>> just copy the text from the new page to the old page and delete the new
>> page.
>
> In general we only grant general permission to make arbitrary feature
> changes to packages in stable releases under specific circumstances[1].
> Probably the relevant reasons in the case of this package would be for
> hardware enablement purposes, or in the case of "Internet protocol"
> changes (eg. for fwupd, perhaps the mechanism to fetch updates is
> changing and will no longer work).
>
> Notably, upstream advertising "EOL dates" is *not* a valid
> justification. Consider this: Ubuntu already commits to supporting an
> LTS release for 10 years. How many upstreams that "publish EOL dates"
> would still be supporting their releases that we shipped by the end of
> that period? I'd guess virtually zero. Clearly, we are committing to
> "LTS-ness" for our entire stable release cycle *despite* "upstream EOL
> dates" - in effect *extending* those dates for our users. Or, consider
> what would happen if "upstream EOL dates" *were* justification for us to
> make major version bumps to our packages. Near the end of our stable
> release cycle, this would mean that we'd effectively become a rolling
> release as every package for which upstream had published an "EOL date"
> would need to be updated. Clearly this is not the intention, so clearly
> "upstream EOL" cannot be a justification in itself for us to bump a
> major version in a stable release.

I think there's a big difference between "not touching" and "supporting".

Due to the LVFS server changes that I've alluded to and Richard
mentioned fwupd from 18.04 LTS and 16.04 are essentially dead software
right now.

In a sense due to the upstream EOL dates the difficulty of "maintaining"
very old versions becomes exponentially greater as the software progresses.

It's not my day job to maintain fwupd but it's something I like to work
on upstream, and I do my best to keep it healthy where and when I can in
Ubuntu.

>
>> I've drafted an updated proposal in this wiki page and aligned it
>> directionally upstream:
>> https://wiki.ubuntu.com/firmware-updates-2.0
>
> One further note from your draft:
>
>> tarball releases only. No backported individual patches.
>
> I understand the benefit of aligning with upstream. However this is only
> possible if upstream policies completely align with distribution policy
> and expectations. There is no guarantee of this in the future, so from a
> policy point of view, distribution-specific patches must never be ruled
> out by a general policy like this. Instead, I expect uploaders and the
> SRU team to continue considering such patches on a case-by-case basis.
> It is normal and a common occurrence for the SRU team to push back on a
> large set of updates and ask for a minimal cherry-pick to minimise risk
> to users, and I don't see any reason that the fwupd should diverge from
> this position. Therefore, IMHO this stipulation cannot form part for a
> policy that the SRU team can accept.

I understand the position; but I have been privy to patches that are
backported "look" like they're compl

Re: [PATCH] drm/amd/amdgpu: Fix 'snprintf' output truncation warning

[Mario Limonciello]

On 5/28/2024 10:24, Pratap Nirujogi wrote:

snprintf can truncate the output fw filename if the isp ucode_prefix
exceeds 29 characters. Knowing ISP ucode_prefix is in the format
isp_x_x_x, limiting the size of ucode_prefix[] to 10 characters
to fix the warning.

Fixes the below warning:

drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c: In function 'isp_early_init':
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:192:58: warning: 'snprintf'
output may be truncated before the last format character
[-Wformat-truncation=]
  192 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", 
ucode_prefix);
  |  ^
In function 'isp_load_fw_by_psp',
inlined from 'isp_early_init' at 
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:218:8:
drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c:192:9: note: 'snprintf' output 
between 12 and 41 bytes into a destination of size 40
  192 | snprintf(fw_name, sizeof(fw_name), "amdgpu/%s.bin", 
ucode_prefix);
  | 
^

Signed-off-by: Pratap Nirujogi 


As the kernel robot reported this you should add a "Reported-by:" tag 
for it.


Otherwise LGTM (feel free to add that tag when committing).

Reviewed-by: Mario Limonciello 


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
index 240408486d6b..2a3f4668cb9b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_isp.c
@@ -96,7 +96,7 @@ static int isp_resume(void *handle)
  static int isp_load_fw_by_psp(struct amdgpu_device *adev)
  {
const struct common_firmware_header *hdr;
-   char ucode_prefix[30];
+   char ucode_prefix[10];
char fw_name[40];
int r = 0;
  

[regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt

[Mario Loffredo]

Hi,

here in the following some comments about this extension:


1)  Don't know how to formally use this extension with HEAD as this 
method doesn't return the body.


Hence, it would represent a case where the server returns an extension 
without signaling it in the rdapConformance array.


2) It seems to me that parsing the HTTP Link header field is trickier 
than parisng the "links" response field.


I'm not aware of well-known HTTP Link Header implementations. I searched 
the web for them and just found out https://github.com/topics/rfc-8288.


I prefer to include all the useful information in the RDAP response 
as JSON parsers are largely used.


3) Wonder how many servers don't include the registrar entity in the 
response to a domain lookup.


The gTLD RDAP response profile requires servers to do that.

As a result, I'm afraid that this extension would be useless.

4) However, it makes sense to me to discuss what could be the most 
likely links returned in the RDAP response and if we really need to 
register some specific rel values detailing the generic "related" 
relation to make RDAP clients to easily identify them or if that is 
profile-specific.


Then, we could discuss if it would be advisable to have RDAP responses 
returning only the link information in addition to the object identifier.


In that case, I agree with Jasdip that registering an ad-hoc field set 
could be a viable option.



Best,

Mario



Il 24/05/2024 18:58, Jasdip Singh ha scritto:


Hi Gavin,

Can RFC 8982 (RDAP Partial Response) [1] not be leveraged to solve this?

Jasdip

[1] https://www.rfc-editor.org/rfc/rfc8982.html

*From: *Maarten Wullink 
*Date: *Friday, May 24, 2024 at 10:28 AM
*To: *Marc Blanchet 
*Cc: *Gavin Brown , Registration Protocols 
Extensions 
*Subject: *[regext] Re: [Ext] New Version Notification for 
draft-brown-rdap-referrals-00.txt


Hi Gavin,

Like Marc, i’m not a big fan of duplicating the link information from 
the json response into the response headers.
However, for the HEAD method request i do see a use case, because in 
this case there exists no data duplication and the client can 
efficiently navigate the Link headers in the response.


anyway, just my 2 cent.

Best,

Maarten


> Op 24 mei 2024, om 15:17 heeft Marc Blanchet 
 het volgende geschreven:

>
> [You don't often get email from marc.blanc...@viagenie.ca. Learn why 
this is important at https://aka.ms/LearnAboutSenderIdentification ]

>
>> Le 24 mai 2024 à 08:10, Gavin Brown  a écrit :
>>
>> Hi all,
>>
>> With my RDAP client implementer hat on, I've been ruminating about 
how the users of my client(s)[1] use them, and some anecdata suggests 
that in general, consumers of registration data - in the domain space 
at least - are often equally if not more interested in the RDAP record 
of the sponsoring registrar than of the registry.

>>
>> Currently, the only way for me to satisfy this user need is to get 
the RDAP record from the registry, parse it to find the "related" 
link, and then requery for that.

>>
>> This draft outlines a possible approach to improving the 
performance of this use case, by putting relevant links into the 
header of the response. The client can then use the HEAD method, 
saving bandwidth and compute resources on both sides, and offering a 
better experience for the user.

>
> I’m also an RDAP client implementer. ;-). and I’ll be playing 
devil’s advocate. The extra query to me is not an issue. Servers of 
RDAP data should already have various caching mechanisms (if not, they 
are in big trouble…) so the hit to a server is insignificant. For the 
client, an extra http query is also insignificant (by comparison, a 
single web page is often 10-20… queries).  For the two step process 
(parsing + query), it is something that a good design would do 
asynchronously so it has no material impact on the user experience or 
UI or else. On the bandwidth usage, for GET request, it will be 
duplication of all links within the RDAP JSON into HTTP headers, 
therefore consuming more bandwidth (and resources). And if we have a 
lot of related links (there are many already), then we are just 
putting a lot of duplicated stuff in the HTTP headers for no necessary 
use. As a client implementor, I’m not sure I should trust the HTTP 
headers, as they may be missing links or maybe wrong: the source of 
truth is the JSON, so I’ll be parsing the JSON anyway. On the server 
side implementation, my guess is that for generality, a server 
implementor may not want to duplicate data, but instead itself parse 
the JSON/database and then extract the links and create HTTP headers, 
in this case, this will be way more work for the server to implement 
this. While I see the idea behind your proposal, I think it may not be 
needed.  At least, I don’t see value for me to implement it. :(

>
> Regards, Marc.
>
>>
>> Feedback

[Bug 2063143] Re: sddm/simpledrm race conditions leads to frequent black display on bootup

[Mario Limonciello]

I posted some idea over to the systemd bug on a way to approach this
from systemd instead of each greeter.

https://github.com/systemd/systemd/issues/32509#issuecomment-2134152084

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  sddm/simpledrm race conditions leads to frequent black display on
  bootup

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063143] Re: sddm/simpledrm race conditions leads to frequent black display on bootup

[Mario Limonciello]

I posted some idea over to the systemd bug on a way to approach this
from systemd instead of each greeter.

https://github.com/systemd/systemd/issues/32509#issuecomment-2134152084

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to sddm in Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  sddm/simpledrm race conditions leads to frequent black display on
  bootup

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
kubuntu-bugs mailing list
kubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs

[Bug 2063983] Re: simpledrm / lightdm race condition leads to black screen

[Mario Limonciello]

The discussion upstream on dri-devel has mostly settled upon userspace greeters 
need to support hot-unplug.
https://lore.kernel.org/dri-devel/ZkyZCmMU86nUV4TO@phenom.ffwll.local/

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063983

Title:
  simpledrm / lightdm race condition leads to black screen

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2063983/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063983] Re: simpledrm / lightdm race condition leads to black screen

[Mario Limonciello]

Can someone with an affected system raise a bug report upstream to lightdm?
There was a very similar bug that occurred in GDM last year:
https://gitlab.gnome.org/GNOME/mutter/-/issues/2909

And there is a similar report opened with SDDM:
https://github.com/sddm/sddm/issues/1917

** Summary changed:

- 24.04 Upgrade/Fresh Install results in black screen on reboot on AMDGPU system
+ simpledrm / lightdm race condition leads to black screen

** Bug watch added: github.com/systemd/systemd/issues #32509
   https://github.com/systemd/systemd/issues/32509

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/32509
   Importance: Unknown
   Status: Unknown

** Bug watch added: gitlab.gnome.org/GNOME/mutter/-/issues #2909
   https://gitlab.gnome.org/GNOME/mutter/-/issues/2909

** Bug watch added: github.com/sddm/sddm/issues #1917
   https://github.com/sddm/sddm/issues/1917

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063983

Title:
  simpledrm / lightdm race condition leads to black screen

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/2063983/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063143] Re: sddm/lightdm race conditions leads to frequent black display on bootup

[Mario Limonciello]

** Summary changed:

- Frequent boot to black display
+ sddm/lightdm race conditions leads to frequent black display on bootup

** Summary changed:

- sddm/lightdm race conditions leads to frequent black display on bootup
+ sddm/simpledrm race conditions leads to frequent black display on bootup

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  sddm/simpledrm race conditions leads to frequent black display on
  bootup

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2063143] Re: sddm/lightdm race conditions leads to frequent black display on bootup

[Mario Limonciello]

** Summary changed:

- Frequent boot to black display
+ sddm/lightdm race conditions leads to frequent black display on bootup

** Summary changed:

- sddm/lightdm race conditions leads to frequent black display on bootup
+ sddm/simpledrm race conditions leads to frequent black display on bootup

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to sddm in Ubuntu.
https://bugs.launchpad.net/bugs/2063143

Title:
  sddm/simpledrm race conditions leads to frequent black display on
  bootup

To manage notifications about this bug go to:
https://bugs.launchpad.net/plymouth/+bug/2063143/+subscriptions


-- 
kubuntu-bugs mailing list
kubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs

[Bug 2063983] Re: 24.04 Upgrade/Fresh Install results in black screen on reboot on AMDGPU system

[Mario Limonciello]

** Package changed: linux (Ubuntu) => lightdm (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063983

Title:
  24.04 Upgrade/Fresh Install results in black screen on reboot on
  AMDGPU system

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/2063983/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065250] Re: My external Diplay Flickers

[Mario Marinero]

Same setup as #2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065250/comments/2

The failing monitor is 1080p old NEC MustySync EA231EMi
The main monitor is 4K, it has no issues

Lowering resolutions to 1600x900 on failing monitor or 1080p on 4k monitor 
solves the issue
Lowering refresh to 50 hz on the failing monitor also solves the issue

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065250

Title:
  My external Diplay Flickers

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065250/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Flying-squirrel-members] Meeting tomorrow

[Mario Savastano]

I have rehearsal upstairs tomorrow night. I will be stopping in for a few
minutes, but won't be available for most of the meeting.

Mario

On Mon, May 27, 2024 at 11:50 AM Christopher Snyder 
wrote:

> Good morning all,
>
> Our squirrel general Meeting is tomorrow at 7pm. I'll be on my way home
> from a funeral in Chicago at that time. I can still call in of someone can
> set up a zoom call in the library. Would anyone be able to set that up for
> me?
>
> Thank you
>
> Christopher
> ___
> Flying-squirrel-members mailing list
> Flying-squirrel-members@lists.rocus.org
> https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members
>
> To unsubscribe, send an email to:
> flying-squirrel-members-unsubscr...@lists.rocus.org
> (The subject and body of the email don't matter)
>
___
Flying-squirrel-members mailing list
Flying-squirrel-members@lists.rocus.org
https://lists.mayfirst.org/mailman/listinfo/flying-squirrel-members

To unsubscribe, send an email to:
flying-squirrel-members-unsubscr...@lists.rocus.org
(The subject and body of the email don't matter)

[PATCH] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Suggested-by: Alex Deucher 
Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_client_modeset.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..b76438c31761 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,27 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   if (connector->connector_type != DRM_MODE_CONNECTOR_eDP || 
!enabled[i])
+   continue;
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +866,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

[PATCH] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Suggested-by: Alex Deucher 
Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_client_modeset.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..b76438c31761 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,27 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   if (connector->connector_type != DRM_MODE_CONNECTOR_eDP || 
!enabled[i])
+   continue;
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +866,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

[PATCH] drm/client: Detect when ACPI lid is closed during initialization

[Mario Limonciello]

If the lid on a laptop is closed when eDP connectors are populated
then it remains enabled when the initial framebuffer configuration
is built.

When creating the initial framebuffer configuration detect the ACPI
lid status and if it's closed disable any eDP connectors.

Suggested-by: Alex Deucher 
Reported-by: Chris Bainbridge 
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3349
Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_client_modeset.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_client_modeset.c 
b/drivers/gpu/drm/drm_client_modeset.c
index 31af5cf37a09..b76438c31761 100644
--- a/drivers/gpu/drm/drm_client_modeset.c
+++ b/drivers/gpu/drm/drm_client_modeset.c
@@ -8,6 +8,7 @@
  */
 
 #include "drm/drm_modeset_lock.h"
+#include 
 #include 
 #include 
 #include 
@@ -257,6 +258,27 @@ static void drm_client_connectors_enabled(struct 
drm_connector **connectors,
enabled[i] = drm_connector_enabled(connectors[i], false);
 }
 
+static void drm_client_match_edp_lid(struct drm_device *dev,
+struct drm_connector **connectors,
+unsigned int connector_count,
+bool *enabled)
+{
+   int i;
+
+   for (i = 0; i < connector_count; i++) {
+   struct drm_connector *connector = connectors[i];
+
+   if (connector->connector_type != DRM_MODE_CONNECTOR_eDP || 
!enabled[i])
+   continue;
+
+   if (!acpi_lid_open()) {
+   drm_dbg_kms(dev, "[CONNECTOR:%d:%s] lid is closed, 
disabling\n",
+   connector->base.id, connector->name);
+   enabled[i] = false;
+   }
+   }
+}
+
 static bool drm_client_target_cloned(struct drm_device *dev,
 struct drm_connector **connectors,
 unsigned int connector_count,
@@ -844,6 +866,7 @@ int drm_client_modeset_probe(struct drm_client_dev *client, 
unsigned int width,
memset(crtcs, 0, connector_count * sizeof(*crtcs));
memset(offsets, 0, connector_count * sizeof(*offsets));
 
+   drm_client_match_edp_lid(dev, connectors, connector_count, 
enabled);
if (!drm_client_target_cloned(dev, connectors, connector_count, 
modes,
  offsets, enabled, width, height) 
&&
!drm_client_target_preferred(dev, connectors, 
connector_count, modes,
-- 
2.43.0

[Bug 2065321] Re: Kubuntu 24.04 Second boot always black screen

[Mario Limonciello]

*** This bug is a duplicate of bug 2063143 ***
https://bugs.launchpad.net/bugs/2063143

** This bug has been marked a duplicate of bug 2063143
   Frequent boot to black display

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065321

Title:
  Kubuntu 24.04 Second boot always black screen

To manage notifications about this bug go to:
https://bugs.launchpad.net/sddm/+bug/2065321/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065321] Re: Kubuntu 24.04 Second boot always black screen

[Mario Limonciello]

*** This bug is a duplicate of bug 2063143 ***
https://bugs.launchpad.net/bugs/2063143

** This bug has been marked a duplicate of bug 2063143
   Frequent boot to black display

-- 
You received this bug notification because you are a member of Kubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2065321

Title:
  Kubuntu 24.04 Second boot always black screen

To manage notifications about this bug go to:
https://bugs.launchpad.net/sddm/+bug/2065321/+subscriptions


-- 
kubuntu-bugs mailing list
kubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kubuntu-bugs

Re: [VOTE] KIP-1040: Improve handling of nullable values in InsertField, ExtractField, and other transformations

[Mario Fiore Vitale]

After 7 days I received only one vote. Should I suppose this will not be
approved?

On Mon, May 20, 2024 at 4:14 PM Chris Egerton 
wrote:

> Thanks for the KIP! +1 (binding)
>
> On Mon, May 20, 2024 at 4:22 AM Mario Fiore Vitale 
> wrote:
>
> > Hi everyone,
> >
> > I'd like to call a vote on KIP-1040 which aims to improve handling of
> > nullable values in InsertField, ExtractField, and other transformations
> >
> > KIP -
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=303794677
> >
> > Discussion thread -
> > https://lists.apache.org/thread/ggqqqjbg6ccpz8g6ztyj7oxr80q5184n
> >
> > Thanks and regards,
> > Mario
> >
>


-- 

Mario Fiore Vitale

Senior Software Engineer

Red Hat <https://www.redhat.com/>
<https://www.redhat.com/>

[PATCH] drm/amd: Fix shutdown (again) on some SMU v13.0.4/11 platforms

[Mario Limonciello]

commit cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for
some SMU 13.0.4/13.0.11 users") attempted to fix shutdown issues
that were reported since commit 31729e8c21ec ("drm/amd/pm: fixes a
random hang in S4 for SMU v13.0.4/11") but caused issues for some
people.

Adjust the workaround flow to properly only apply in the S4 case:
-> For shutdown go through SMU_MSG_PrepareMp1ForUnload
-> For S4 go through SMU_MSG_GfxDeviceDriverReset and
   SMU_MSG_PrepareMp1ForUnload

Reported-and-tested-by: lectrode 
Closes: https://github.com/void-linux/void-packages/issues/50417
Cc: sta...@vger.kernel.org
Fixes: cd94d1b182d2 ("dm/amd/pm: Fix problems with reboot/shutdown for some SMU 
13.0.4/13.0.11 users")
Signed-off-by: Mario Limonciello 
---
Cc: regressi...@lists.linux.dev
---
 .../drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c  | 20 ++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c 
b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
index 4abfcd32747d..c7ab0d7027d9 100644
--- a/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
+++ b/drivers/gpu/drm/amd/pm/swsmu/smu13/smu_v13_0_4_ppt.c
@@ -226,15 +226,17 @@ static int smu_v13_0_4_system_features_control(struct 
smu_context *smu, bool en)
struct amdgpu_device *adev = smu->adev;
int ret = 0;
 
-   if (!en && adev->in_s4) {
-   /* Adds a GFX reset as workaround just before sending the
-* MP1_UNLOAD message to prevent GC/RLC/PMFW from entering
-* an invalid state.
-*/
-   ret = smu_cmn_send_smc_msg_with_param(smu, 
SMU_MSG_GfxDeviceDriverReset,
- SMU_RESET_MODE_2, NULL);
-   if (ret)
-   return ret;
+   if (!en && !adev->in_s0ix) {
+   if (adev->in_s4) {
+   /* Adds a GFX reset as workaround just before sending 
the
+* MP1_UNLOAD message to prevent GC/RLC/PMFW from 
entering
+* an invalid state.
+*/
+   ret = smu_cmn_send_smc_msg_with_param(smu, 
SMU_MSG_GfxDeviceDriverReset,
+   SMU_RESET_MODE_2, NULL);
+   if (ret)
+   return ret;
+   }
 
ret = smu_cmn_send_smc_msg(smu, SMU_MSG_PrepareMp1ForUnload, 
NULL);
}
-- 
2.43.0

[Discover] [Bug 487442] Discover crashes when tiling and then resizing the window to a very small size.

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487442

--- Comment #4 from Mario Ebenhofer  ---
I just tried it again, and the part about the window being so narrow only
happens after I tiled another window there and resized it.
If I don't do that before, Discover takes up half of the screen like normal,
but I can still make it smaller and cause the crash.

Also, did you test it on such a rotated (and therefore narrow) display, too?
I also attached a screenshot of my current display configuration.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Discover] [Bug 487442] Discover crashes when tiling and then resizing the window to a very small size.

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487442

--- Comment #3 from Mario Ebenhofer  ---
Created attachment 169775
  --> https://bugs.kde.org/attachment.cgi?id=169775=edit
Display configuration

The issue only occurs on the 90° rotated HP Display.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Discover] [Bug 487442] Discover crashes when tiling and then resizing the window to a very small size.

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487442

--- Comment #1 from Mario Ebenhofer  ---
Also, I could not replicate that issue on my other monitors, only on one 90°
rotated 1920x1080 monitor, so it's probably only on very slim displays.

-- 
You are receiving this mail because:
You are watching all bug changes.

[Discover] [Bug 487442] New: Discover crashes when tiling and then resizing the window to a very small size.

[Mario Ebenhofer]

https://bugs.kde.org/show_bug.cgi?id=487442

Bug ID: 487442
   Summary: Discover crashes when tiling and then resizing the
window to a very small size.
Classification: Applications
   Product: Discover
   Version: 6.0.4
  Platform: Fedora RPMs
OS: Linux
Status: REPORTED
  Severity: crash
  Priority: NOR
 Component: discover
  Assignee: plasma-b...@kde.org
  Reporter: mano...@mailbox.org
CC: aleix...@kde.org
  Target Milestone: ---

Created attachment 169749
  --> https://bugs.kde.org/attachment.cgi?id=169749=edit
Screen recording of the crash (and what I did before)

SUMMARY
Discover crashes when tiling and then resizing the window to a very small size
on Fedora 40 KDE (wayland, nvidia)

STEPS TO REPRODUCE
1. Open Discover
2. Move the window to the edge of a monitor to "tile" it to one side.
3. Resize the window to a small width (that is normally not possible without
first tiling it)

OBSERVED RESULT
Discover becomes unresponsive. It can no longer be resized, or maximized.
After clicking the "Minimize" or "Close" button, the window becomes grey and a
promt to end the process appears.
A screen recording is attached.

EXPECTED RESULT
Discover either not letting me resize it to such a small size or not crashing
when resized.

SOFTWARE/OS VERSIONS

Discover Version: 6.0.4
Operating System: Fedora Linux 40
KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0
Kernel Version: 6.9.1-cb1.0.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 6 × Intel® Core™ i5-8600K CPU @ 3.60GHz
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1060 6GB/PCIe/SSE2

ADDITIONAL INFORMATION

Terminal output:

~$ plasma-discover
org.kde.plasma.libdiscover: OdrsReviewsBackend: Fetch ratings: false
adding empty sources model QStandardItemModel(0x64994a91eed0)
qrc:/qt/qml/org/kde/discover/qml/DiscoverWindow.qml:330:5: QML OverlaySheet:
Binding loop detected for property "implicitHeight"
qrc:/qt/qml/org/kde/discover/qml/BrowsingPage.qml:17:1: QML BrowsingPage:
Created graphical object was not placed in the graphics scene.
QQuickItem::stackBefore: Cannot stack QQuickRectangle(0x64994c51e2d0,
parent=0x64994a750300, geometry=0,0 0x0) before
QQuickPopupItem(0x64994a81eea0), which must be a sibling
Killed


GDB Backtrace (although I don't think that's any more useful than the console
output above):

[New Thread 0x7fff82a006c0 (LWP 16408)] 
[Thread 0x7fffb3e006c0 (LWP 16375) exited]
[Thread 0x7fff9aa006c0 (LWP 16386) exited]
[New Thread 0x7fff9aa006c0 (LWP 16413)]
[New Thread 0x7fffb3e006c0 (LWP 16414)]
[Thread 0x7fff9be006c0 (LWP 16384) exited]
[Thread 0x7fffb3e006c0 (LWP 16414) exited]
[New Thread 0x7fffb3e006c0 (LWP 16419)]
[New Thread 0x7fff9be006c0 (LWP 16420)]
[Thread 0x7fff9aa006c0 (LWP 16413) exited]
QQuickItem::stackBefore: Cannot stack QQuickRectangle(0x56576f30,
parent=0x55d741a0, geometry=0,0 0x0) before
QQuickPopupItem(0x55c60030), which must be a sibling
[Thread 0x7fff8dc006c0 (LWP 16392) exited]
[New Thread 0x7fff9be006c0 (LWP 16425)]
[Thread 0x7fff9be006c0 (LWP 16420) exited]
[New Thread 0x7fff8dc006c0 (LWP 16426)]
[Thread 0x7fffb3e006c0 (LWP 16419) exited]
[Thread 0x7fff8dc006c0 (LWP 16426) exited]
[New Thread 0x7fff8dc006c0 (LWP 16427)]
[New Thread 0x7fffb3e006c0 (LWP 16428)]
[Thread 0x7fff9be006c0 (LWP 16425) exited]
[Thread 0x7fffb3e006c0 (LWP 16428) exited]
[New Thread 0x7fffb3e006c0 (LWP 16429)]
[New Thread 0x7fff9be006c0 (LWP 16430)]
[Thread 0x7fff8dc006c0 (LWP 16427) exited]
[Thread 0x7fff9be006c0 (LWP 16430) exited]
[New Thread 0x7fff9be006c0 (LWP 16431)]
[Thread 0x7fffb3e006c0 (LWP 16429) exited]
[New Thread 0x7fff8dc006c0 (LWP 16432)]
[New Thread 0x7fff8dc006c0 (LWP 16433)]
[Thread 0x7fff8dc006c0 (LWP 16432) exited]
[New Thread 0x7fffb3e006c0 (LWP 16434)]
[Thread 0x7fff9be006c0 (LWP 16431) exited]
[New Thread 0x7fffb3e006c0 (LWP 16435)]
[Thread 0x7fffb3e006c0 (LWP 16434) exited]
[Thread 0x7fff8dc006c0 (LWP 16433) exited]
[New Thread 0x7fff9be006c0 (LWP 16436)]
[Thread 0x7fff9be006c0 (LWP 16436) exited]
[Thread 0x7fffb3e006c0 (LWP 16435) exited]
[New Thread 0x7fff9be006c0 (LWP 16437)]
[New Thread 0x7fff8dc006c0 (LWP 16438)]
[Thread 0x7fff8dc006c0 (LWP 16438) exited]
[New Thread 0x7fff8dc006c0 (LWP 16439)]
[New Thread 0x7fffb3e006c0 (LWP 16440)]
[Thread 0x7fff9be006c0 (LWP 16437) exited]
[Thread 0x7fffb3e006c0 (LWP 16440) exited]
[New Thread 0x7fffb3e006c0 (LWP 16441)]
[Thread 0x7fff8dc006c0 (LWP 16439) exited]
[New Thread 0x7fff9be006c0 (LWP 16442)]
[Thread 0x7fff9be006c0 (LWP 16442) exited]
[New Thread 0x7fff9be006c0 (LWP 16443)]
[New Thread 0x7fff8dc006c0 (LWP 16444)]
[Thread 0x7fffb3e006c0 (LWP 16441) exited]
[Thread 0x7fff8dc006c0 (LWP 16444) exited]
[New Thread 0x7fff8dc006c0 (LWP 16445)]
[New Thread 0x7fffb3e006c0 (LWP 16446)]
[Thread 0x7fff9be006c0 (LWP 16443) exited]

[Bug 2066345] Re: Lenovo T14 Gen3 AMD laptop lid suspend freezes system

[Mario Limonciello]

This should be a duplicate of 
https://bugs.launchpad.net/ubuntu/+source/linux-oem-6.5/+bug/2064595
The fix is 
https://github.com/torvalds/linux/commit/ca299b4512d4b4f516732a48ce9aa19d91f4473e

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066345

Title:
  Lenovo T14 Gen3 AMD laptop lid suspend freezes system

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2066345/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2065838] Re: System crash on resume from sleep

[Mario Limonciello]

Do you have secure boot enabled?  if so, turn it off and hopefully the
kernel you built should be bootadble.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2065838

Title:
  System crash on resume from sleep

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065838/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 2066293] Re: External screen Flickering in Ubuntu 24.04

[Mario Marinero]

It may be a duplicate of
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2065250, but
hardware is different

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2066293

Title:
  External screen Flickering in Ubuntu 24.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/2066293/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[PATCH v2 3/4] tests/amdgpu/amd_abm: Add support for panel_power_saving property

[Mario Limonciello]

From: Mario Limonciello 

When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to have color
accuracy and fidelity instead of power saving.

Verify that the sysfs file behaves as expected in this situation.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index f74c3012c..3fa1366fa 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -365,6 +365,43 @@ static void abm_gradual(data_t *data)
}
 }
 
+
+static void abm_forbidden(data_t *data)
+{
+   igt_output_t *output;
+   enum pipe pipe;
+   int target, r;
+
+   for_each_pipe_with_valid_output(>display, pipe, output) {
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+
+   r = clear_power_saving_policy(data->drm_fd, output);
+   if (r == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_assert_eq(r, 0);
+
+   target = 3;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+
+   r = set_panel_power_saving_policy(data->drm_fd, output, 
DRM_MODE_REQUIRE_COLOR_ACCURACY);
+   igt_assert_eq(r, 0);
+
+   target = 0;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, -1);
+
+   r = clear_power_saving_policy(data->drm_fd, output);
+   igt_assert_eq(r, 0);
+
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+   }
+}
+
 igt_main
 {
data_t data = {};
@@ -393,6 +430,8 @@ igt_main
abm_enabled();
igt_subtest("abm_gradual")
abm_gradual();
+   igt_subtest("abm_forbidden")
+   abm_forbidden();
 
igt_fixture {
igt_display_fini();
-- 
2.43.0

[PATCH v2 4/4] tests/amdgpu/amd_psr: Add support for `power saving policy` property

[Mario Limonciello]

Verify that the property has disabled PSR
---
 tests/amdgpu/amd_psr.c | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/tests/amdgpu/amd_psr.c b/tests/amdgpu/amd_psr.c
index 9da161a09..a9f4a6aa5 100644
--- a/tests/amdgpu/amd_psr.c
+++ b/tests/amdgpu/amd_psr.c
@@ -338,6 +338,78 @@ static void run_check_psr(data_t *data, bool 
test_null_crtc) {
test_fini(data);
 }
 
+static void psr_forbidden(data_t *data)
+{
+   int edp_idx, ret, i, psr_state;
+   igt_fb_t ref_fb, ref_fb2;
+   igt_fb_t *flip_fb;
+   igt_output_t *output;
+
+   test_init(data);
+
+   edp_idx = check_conn_type(data, DRM_MODE_CONNECTOR_eDP);
+   igt_skip_on_f(edp_idx == -1, "no eDP connector found\n");
+
+   /* check if eDP support PSR1, PSR-SU.
+*/
+   igt_skip_on(!psr_mode_supported(data, PSR_MODE_1) && 
!psr_mode_supported(data, PSR_MODE_2));
+   for_each_connected_output(>display, output) {
+
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+   ret = clear_power_saving_policy(data->fd, output);
+   if (ret == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_require(ret == 0);
+
+   /* try to engage PSR */
+   ret = set_panel_power_saving_policy(data->fd, output, 
DRM_MODE_REQUIRE_LOW_LATENCY);
+   igt_assert_eq(ret, 0);
+
+   igt_create_color_fb(data->fd, data->mode->hdisplay,
+   data->mode->vdisplay, DRM_FORMAT_XRGB, 
0, 1.0,
+   0.0, 0.0, _fb);
+   igt_create_color_fb(data->fd, data->mode->hdisplay,
+   data->mode->vdisplay, DRM_FORMAT_XRGB, 
0, 0.0,
+   1.0, 0.0, _fb2);
+
+   igt_plane_set_fb(data->primary, _fb);
+
+   igt_display_commit_atomic(>display, 
DRM_MODE_ATOMIC_ALLOW_MODESET, 0);
+
+   for (i = 0; i < N_FLIPS; i++) {
+   if (i % 2 == 0)
+   flip_fb = _fb2;
+   else
+   flip_fb = _fb;
+
+   ret = drmModePageFlip(data->fd, 
output->config.crtc->crtc_id,
+ flip_fb->fb_id, 
DRM_MODE_PAGE_FLIP_EVENT, NULL);
+   igt_require(ret == 0);
+   kmstest_wait_for_pageflip(data->fd);
+   }
+
+   /* PSR state takes some time to settle its value on static 
screen */
+   sleep(PSR_SETTLE_DELAY);
+
+   psr_state =  igt_amd_read_psr_state(data->fd, output->name);
+   igt_require(psr_state == PSR_STATE3);
+
+   igt_remove_fb(data->fd, _fb);
+   igt_remove_fb(data->fd, _fb2);
+
+   ret = clear_power_saving_policy(data->fd, output);
+   if (ret == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_require(ret == 0);
+
+   }
+}
+
 static void run_check_psr_su_mpo(data_t *data, bool scaling, float 
scaling_ratio)
 {
int edp_idx = check_conn_type(data, DRM_MODE_CONNECTOR_eDP);
@@ -756,6 +828,8 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
igt_describe("Test to validate PSR SU enablement with Visual Confirm "
 "and to validate PSR SU disable/re-enable w/ primary 
scaling ratio 0.75");
igt_subtest("psr_su_mpo_scaling_0_75") run_check_psr_su_mpo(, 
true, .75);
+   igt_describe("Test whether PSR can be forbidden");
+   igt_subtest("psr_forbidden") psr_forbidden();
 
igt_fixture
{
-- 
2.43.0

[PATCH v2 3/4] tests/amdgpu/amd_abm: Add support for panel_power_saving property

[Mario Limonciello]

From: Mario Limonciello 

When the "panel power saving" property is set to forbidden the
compositor has indicated that userspace prefers to have color
accuracy and fidelity instead of power saving.

Verify that the sysfs file behaves as expected in this situation.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index f74c3012c..3fa1366fa 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -365,6 +365,43 @@ static void abm_gradual(data_t *data)
}
 }
 
+
+static void abm_forbidden(data_t *data)
+{
+   igt_output_t *output;
+   enum pipe pipe;
+   int target, r;
+
+   for_each_pipe_with_valid_output(>display, pipe, output) {
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+
+   r = clear_power_saving_policy(data->drm_fd, output);
+   if (r == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_assert_eq(r, 0);
+
+   target = 3;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+
+   r = set_panel_power_saving_policy(data->drm_fd, output, 
DRM_MODE_REQUIRE_COLOR_ACCURACY);
+   igt_assert_eq(r, 0);
+
+   target = 0;
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, -1);
+
+   r = clear_power_saving_policy(data->drm_fd, output);
+   igt_assert_eq(r, 0);
+
+   r = set_abm_level(data, output, target);
+   igt_assert_eq(r, 0);
+   }
+}
+
 igt_main
 {
data_t data = {};
@@ -393,6 +430,8 @@ igt_main
abm_enabled();
igt_subtest("abm_gradual")
abm_gradual();
+   igt_subtest("abm_forbidden")
+   abm_forbidden();
 
igt_fixture {
igt_display_fini();
-- 
2.43.0

[PATCH v2 2/4] tests/amdgpu/amd_abm: Make set_abm_level return type int

[Mario Limonciello]

From: Mario Limonciello 

In order to bubble of cases of expeted errors on set_abm_level()
change the return type to int.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index 2882c2c18..f74c3012c 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,10 +104,11 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
-static void set_abm_level(data_t *data, igt_output_t *output, int level)
+static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
int fd;
+   int ret;
 
igt_assert(snprintf(buf, PATH_MAX, PANEL_POWER_SAVINGS_PATH,
output->name) < PATH_MAX);
@@ -116,8 +117,12 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 
igt_assert(fd != -1);
 
-   igt_assert_eq(snprintf(buf, sizeof(buf), "%d", level),
- write(fd, buf, 1));
+   snprintf(buf, sizeof(buf), "%d", level);
+   ret = write(fd, buf, 1);
+   if (ret < 0) {
+   close(fd);
+   return ret;
+   }
 
igt_assert_eq(close(fd), 0);
 
@@ -129,6 +134,7 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 DRM_MODE_DPMS_OFF);
kmstest_set_connector_dpms(data->drm_fd, output->config.connector,
 DRM_MODE_DPMS_ON);
+   return 0;
 }
 
 static int backlight_read_max_brightness(int *result)
@@ -192,7 +198,8 @@ static void backlight_dpms_cycle(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness / 2);
usleep(10);
pwm_1 = read_target_backlight_pwm(data->drm_fd, output->name);
@@ -223,7 +230,8 @@ static void backlight_monotonic_basic(data_t *data)
 
brightness_step = max_brightness / 10;
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -257,7 +265,8 @@ static void backlight_monotonic_abm(data_t *data)
 
brightness_step = max_brightness / 10;
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -289,14 +298,16 @@ static void abm_enabled(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
pwm_without_abm = prev_pwm;
 
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, i);
+   ret = set_abm_level(data, output, i);
+   igt_assert_eq(ret, 0);
usleep(10);
pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
igt_assert(pwm <= prev_pwm);
@@ -323,7 +334,8 @@ static void abm_gradual(data_t *data)
 
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
 
sleep(convergence_delay);
@@ -331,7 +343,8 @@ static void abm_gradual(data_t *data)
curr = read_current_backlight_pwm(data->drm_fd, output->name);
 
igt_assert_eq(prev_pwm, curr);
-   set_abm_level(data, output, 4);
+   ret = set_abm_level(data, output, 4);
+   igt_assert_eq(ret, 0);
for (i = 0; i < 10; i++) {
usleep(10);
pwm = read_current_backlight_pwm(data->drm_fd, 
output->name);
-- 
2.43.0

[PATCH v2 2/4] tests/amdgpu/amd_abm: Make set_abm_level return type int

[Mario Limonciello]

From: Mario Limonciello 

In order to bubble of cases of expeted errors on set_abm_level()
change the return type to int.

Signed-off-by: Mario Limonciello 
---
 tests/amdgpu/amd_abm.c | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/tests/amdgpu/amd_abm.c b/tests/amdgpu/amd_abm.c
index 2882c2c18..f74c3012c 100644
--- a/tests/amdgpu/amd_abm.c
+++ b/tests/amdgpu/amd_abm.c
@@ -104,10 +104,11 @@ static int backlight_write_brightness(int value)
return 0;
 }
 
-static void set_abm_level(data_t *data, igt_output_t *output, int level)
+static int set_abm_level(data_t *data, igt_output_t *output, int level)
 {
char buf[PATH_MAX];
int fd;
+   int ret;
 
igt_assert(snprintf(buf, PATH_MAX, PANEL_POWER_SAVINGS_PATH,
output->name) < PATH_MAX);
@@ -116,8 +117,12 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 
igt_assert(fd != -1);
 
-   igt_assert_eq(snprintf(buf, sizeof(buf), "%d", level),
- write(fd, buf, 1));
+   snprintf(buf, sizeof(buf), "%d", level);
+   ret = write(fd, buf, 1);
+   if (ret < 0) {
+   close(fd);
+   return ret;
+   }
 
igt_assert_eq(close(fd), 0);
 
@@ -129,6 +134,7 @@ static void set_abm_level(data_t *data, igt_output_t 
*output, int level)
 DRM_MODE_DPMS_OFF);
kmstest_set_connector_dpms(data->drm_fd, output->config.connector,
 DRM_MODE_DPMS_ON);
+   return 0;
 }
 
 static int backlight_read_max_brightness(int *result)
@@ -192,7 +198,8 @@ static void backlight_dpms_cycle(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness / 2);
usleep(10);
pwm_1 = read_target_backlight_pwm(data->drm_fd, output->name);
@@ -223,7 +230,8 @@ static void backlight_monotonic_basic(data_t *data)
 
brightness_step = max_brightness / 10;
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -257,7 +265,8 @@ static void backlight_monotonic_abm(data_t *data)
 
brightness_step = max_brightness / 10;
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
@@ -289,14 +298,16 @@ static void abm_enabled(data_t *data)
ret = backlight_read_max_brightness(_brightness);
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
usleep(10);
prev_pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
pwm_without_abm = prev_pwm;
 
for (i = 1; i < 5; i++) {
-   set_abm_level(data, output, i);
+   ret = set_abm_level(data, output, i);
+   igt_assert_eq(ret, 0);
usleep(10);
pwm = read_target_backlight_pwm(data->drm_fd, 
output->name);
igt_assert(pwm <= prev_pwm);
@@ -323,7 +334,8 @@ static void abm_gradual(data_t *data)
 
igt_assert_eq(ret, 0);
 
-   set_abm_level(data, output, 0);
+   ret = set_abm_level(data, output, 0);
+   igt_assert_eq(ret, 0);
backlight_write_brightness(max_brightness);
 
sleep(convergence_delay);
@@ -331,7 +343,8 @@ static void abm_gradual(data_t *data)
curr = read_current_backlight_pwm(data->drm_fd, output->name);
 
igt_assert_eq(prev_pwm, curr);
-   set_abm_level(data, output, 4);
+   ret = set_abm_level(data, output, 4);
+   igt_assert_eq(ret, 0);
for (i = 0; i < 10; i++) {
usleep(10);
pwm = read_current_backlight_pwm(data->drm_fd, 
output->name);
-- 
2.43.0

[PATCH v2 4/4] tests/amdgpu/amd_psr: Add support for `power saving policy` property

[Mario Limonciello]

Verify that the property has disabled PSR
---
 tests/amdgpu/amd_psr.c | 74 ++
 1 file changed, 74 insertions(+)

diff --git a/tests/amdgpu/amd_psr.c b/tests/amdgpu/amd_psr.c
index 9da161a09..a9f4a6aa5 100644
--- a/tests/amdgpu/amd_psr.c
+++ b/tests/amdgpu/amd_psr.c
@@ -338,6 +338,78 @@ static void run_check_psr(data_t *data, bool 
test_null_crtc) {
test_fini(data);
 }
 
+static void psr_forbidden(data_t *data)
+{
+   int edp_idx, ret, i, psr_state;
+   igt_fb_t ref_fb, ref_fb2;
+   igt_fb_t *flip_fb;
+   igt_output_t *output;
+
+   test_init(data);
+
+   edp_idx = check_conn_type(data, DRM_MODE_CONNECTOR_eDP);
+   igt_skip_on_f(edp_idx == -1, "no eDP connector found\n");
+
+   /* check if eDP support PSR1, PSR-SU.
+*/
+   igt_skip_on(!psr_mode_supported(data, PSR_MODE_1) && 
!psr_mode_supported(data, PSR_MODE_2));
+   for_each_connected_output(>display, output) {
+
+   if (output->config.connector->connector_type != 
DRM_MODE_CONNECTOR_eDP)
+   continue;
+   ret = clear_power_saving_policy(data->fd, output);
+   if (ret == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_require(ret == 0);
+
+   /* try to engage PSR */
+   ret = set_panel_power_saving_policy(data->fd, output, 
DRM_MODE_REQUIRE_LOW_LATENCY);
+   igt_assert_eq(ret, 0);
+
+   igt_create_color_fb(data->fd, data->mode->hdisplay,
+   data->mode->vdisplay, DRM_FORMAT_XRGB, 
0, 1.0,
+   0.0, 0.0, _fb);
+   igt_create_color_fb(data->fd, data->mode->hdisplay,
+   data->mode->vdisplay, DRM_FORMAT_XRGB, 
0, 0.0,
+   1.0, 0.0, _fb2);
+
+   igt_plane_set_fb(data->primary, _fb);
+
+   igt_display_commit_atomic(>display, 
DRM_MODE_ATOMIC_ALLOW_MODESET, 0);
+
+   for (i = 0; i < N_FLIPS; i++) {
+   if (i % 2 == 0)
+   flip_fb = _fb2;
+   else
+   flip_fb = _fb;
+
+   ret = drmModePageFlip(data->fd, 
output->config.crtc->crtc_id,
+ flip_fb->fb_id, 
DRM_MODE_PAGE_FLIP_EVENT, NULL);
+   igt_require(ret == 0);
+   kmstest_wait_for_pageflip(data->fd);
+   }
+
+   /* PSR state takes some time to settle its value on static 
screen */
+   sleep(PSR_SETTLE_DELAY);
+
+   psr_state =  igt_amd_read_psr_state(data->fd, output->name);
+   igt_require(psr_state == PSR_STATE3);
+
+   igt_remove_fb(data->fd, _fb);
+   igt_remove_fb(data->fd, _fb2);
+
+   ret = clear_power_saving_policy(data->fd, output);
+   if (ret == -ENODEV) {
+   igt_skip("No power saving policy prop\n");
+   return;
+   }
+   igt_require(ret == 0);
+
+   }
+}
+
 static void run_check_psr_su_mpo(data_t *data, bool scaling, float 
scaling_ratio)
 {
int edp_idx = check_conn_type(data, DRM_MODE_CONNECTOR_eDP);
@@ -756,6 +828,8 @@ igt_main_args("", long_options, help_str, opt_handler, NULL)
igt_describe("Test to validate PSR SU enablement with Visual Confirm "
 "and to validate PSR SU disable/re-enable w/ primary 
scaling ratio 0.75");
igt_subtest("psr_su_mpo_scaling_0_75") run_check_psr_su_mpo(, 
true, .75);
+   igt_describe("Test whether PSR can be forbidden");
+   igt_subtest("psr_forbidden") psr_forbidden();
 
igt_fixture
{
-- 
2.43.0

[PATCH v2 0/4] Add support for testing power saving policy DRM property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity or low latency is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
by the compositor to for it's requirements.

When a driver advertises support for this property and the compositor
sets requirements then the driver will disable any appplicable power saving
features that can compromise the requirements.

This set of IGT changes introduces a new subtest that will cover the
expected kernel behavior when switching between requirements.

Mario Limonciello (4):
  Add support for API for drivers to set power saving policy
  tests/amdgpu/amd_abm: Make set_abm_level return type int
  tests/amdgpu/amd_abm: Add support for panel_power_saving property
  tests/amdgpu/amd_psr: Add support for `power saving policy` property

 lib/igt_kms.c  | 26 +++
 lib/igt_kms.h  |  6 
 tests/amdgpu/amd_abm.c | 72 ++--
 tests/amdgpu/amd_psr.c | 74 ++
 4 files changed, 168 insertions(+), 10 deletions(-)

-- 
2.43.0

[PATCH v2 1/4] Add support for API for drivers to set power saving policy

[Mario Limonciello]

---
 lib/igt_kms.c | 26 ++
 lib/igt_kms.h |  6 ++
 2 files changed, 32 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index af63d13b1..4ce5e4a95 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -6581,3 +6581,29 @@ int get_num_scalers(int drm_fd, enum pipe pipe)
 
return num_scalers;
 }
+
+static int toggle_power_saving_policy_prop(int drm_fd, igt_output_t *output, 
uint64_t policy)
+{
+   uint32_t type = DRM_MODE_OBJECT_CONNECTOR;
+   bool prop_exists;
+   uint32_t prop_id;
+
+   prop_exists = kmstest_get_property(
+   drm_fd, output->id, type, "power saving policy",
+   _id, NULL, NULL);
+
+   if (!prop_exists)
+   return -ENODEV;
+
+   return drmModeObjectSetProperty(drm_fd, output->id, type, prop_id, 
policy);
+}
+
+int clear_power_saving_policy(int drm_fd, igt_output_t *output)
+{
+   return toggle_power_saving_policy_prop(drm_fd, output, 0);
+}
+
+int set_panel_power_saving_policy(int drm_fd, igt_output_t *output, uint64_t 
policy)
+{
+   return toggle_power_saving_policy_prop(drm_fd, output, policy);
+}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 01604dac9..129b88576 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -1223,4 +1223,10 @@ bool igt_check_output_is_dp_mst(igt_output_t *output);
 int igt_get_dp_mst_connector_id(igt_output_t *output);
 int get_num_scalers(int drm_fd, enum pipe pipe);
 
+#define DRM_MODE_REQUIRE_COLOR_ACCURACYBIT(0)  /* Compositor requires 
color accuracy */
+#define DRM_MODE_REQUIRE_LOW_LATENCY   BIT(1)  /* Compositor requires low 
latency */
+
+int clear_power_saving_policy(int drm_fd, igt_output_t *output);
+int set_panel_power_saving_policy(int drm_fd, igt_output_t *output, uint64_t 
policy);
+
 #endif /* __IGT_KMS_H__ */
-- 
2.43.0

[PATCH v2 1/4] Add support for API for drivers to set power saving policy

[Mario Limonciello]

---
 lib/igt_kms.c | 26 ++
 lib/igt_kms.h |  6 ++
 2 files changed, 32 insertions(+)

diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index af63d13b1..4ce5e4a95 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -6581,3 +6581,29 @@ int get_num_scalers(int drm_fd, enum pipe pipe)
 
return num_scalers;
 }
+
+static int toggle_power_saving_policy_prop(int drm_fd, igt_output_t *output, 
uint64_t policy)
+{
+   uint32_t type = DRM_MODE_OBJECT_CONNECTOR;
+   bool prop_exists;
+   uint32_t prop_id;
+
+   prop_exists = kmstest_get_property(
+   drm_fd, output->id, type, "power saving policy",
+   _id, NULL, NULL);
+
+   if (!prop_exists)
+   return -ENODEV;
+
+   return drmModeObjectSetProperty(drm_fd, output->id, type, prop_id, 
policy);
+}
+
+int clear_power_saving_policy(int drm_fd, igt_output_t *output)
+{
+   return toggle_power_saving_policy_prop(drm_fd, output, 0);
+}
+
+int set_panel_power_saving_policy(int drm_fd, igt_output_t *output, uint64_t 
policy)
+{
+   return toggle_power_saving_policy_prop(drm_fd, output, policy);
+}
diff --git a/lib/igt_kms.h b/lib/igt_kms.h
index 01604dac9..129b88576 100644
--- a/lib/igt_kms.h
+++ b/lib/igt_kms.h
@@ -1223,4 +1223,10 @@ bool igt_check_output_is_dp_mst(igt_output_t *output);
 int igt_get_dp_mst_connector_id(igt_output_t *output);
 int get_num_scalers(int drm_fd, enum pipe pipe);
 
+#define DRM_MODE_REQUIRE_COLOR_ACCURACYBIT(0)  /* Compositor requires 
color accuracy */
+#define DRM_MODE_REQUIRE_LOW_LATENCY   BIT(1)  /* Compositor requires low 
latency */
+
+int clear_power_saving_policy(int drm_fd, igt_output_t *output);
+int set_panel_power_saving_policy(int drm_fd, igt_output_t *output, uint64_t 
policy);
+
 #endif /* __IGT_KMS_H__ */
-- 
2.43.0

[PATCH v2 0/4] Add support for testing power saving policy DRM property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity or low latency is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
by the compositor to for it's requirements.

When a driver advertises support for this property and the compositor
sets requirements then the driver will disable any appplicable power saving
features that can compromise the requirements.

This set of IGT changes introduces a new subtest that will cover the
expected kernel behavior when switching between requirements.

Mario Limonciello (4):
  Add support for API for drivers to set power saving policy
  tests/amdgpu/amd_abm: Make set_abm_level return type int
  tests/amdgpu/amd_abm: Add support for panel_power_saving property
  tests/amdgpu/amd_psr: Add support for `power saving policy` property

 lib/igt_kms.c  | 26 +++
 lib/igt_kms.h  |  6 
 tests/amdgpu/amd_abm.c | 72 ++--
 tests/amdgpu/amd_psr.c | 74 ++
 4 files changed, 168 insertions(+), 10 deletions(-)

-- 
2.43.0

[PATCH v2 1/2] drm: Introduce 'power saving policy' drm property

[Mario Limonciello]

The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_connector.c | 46 +
 include/drm/drm_connector.h |  2 ++
 include/drm/drm_mode_config.h   |  5 
 include/uapi/drm/drm_mode.h |  7 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..088a5874c7a4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
+   { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color 
accuracy" },
+   { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low 
latency" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1499,6 +1504,16 @@ static const u32 dp_colorspaces =
  *
  * Drivers can set up these properties by calling
  * drm_mode_create_tv_margin_properties().
+ * power saving policy:
+ * This property is used to set the power saving policy for the connector.
+ * This property is populated with a bitmask of optional requirements set
+ * by the drm master for the drm driver to respect:
+ * - "Require color accuracy": Disable power saving features that will
+ *   affect color fidelity.
+ *   For example: Hardware assisted backlight modulation.
+ * - "Require low latency": Disable power saving features that will
+ *   affect latency.
+ *   For example: Panel self refresh (PSR)
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1963,6 +1978,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_power_saving_policy_property - create power saving policy 
property
+ * @dev: DRM device
+ * @supported_policies: bitmask of supported power saving policies
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies)
+{
+   struct drm_property *power_saving;
+
+   if (dev->mode_config.power_saving_policy)
+   return 0;
+   WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
+
+   power_saving =
+   drm_property_create_bitmask(dev, 0, "power saving policy",
+   drm_power_saving_policy_enum_list,
+   
ARRAY_SIZE(drm_power_saving_policy_enum_list),
+   supported_policies);
+
+   dev->mode_config.power_saving_policy = power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..b0ec2ec48de7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,8 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..32077e701e2f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -954,6 +954,11 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @power_saving_policy: bitmask for power saving policy requests.
+*/
+   struct drm_property *power_saving_policy;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7040e7ea80c7..c2c86623552c 100644
--- a/include/uapi/d

[PATCH v2 0/2] Add support for 'power saving policy' property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
with requests of "Require color accuracy" or "Require low latency"
that can be configured by the compositor.

When a driver advertises support for this property and the compositor
sets it to "Require color accuracy" then the driver will disable any power
saving features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Require color accuracy" then
this feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

Compositors can also request that low latency is critical which in practice
should cause PSR and PSR2 to be disabled.

When the compositor has restored the value back to no requirements then the
previous value that would have been programmed will be restored.

---
v1->v2:
 * New property as a bitmask
 * Handle both ABM and PSR/PSR2
 * Add documentation

Mario Limonciello (2):
  drm: Introduce 'power saving policy' drm property
  drm/amd: Add power_saving_policy drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 drivers/gpu/drm/drm_connector.c   | 46 +
 include/drm/drm_connector.h   |  2 +
 include/drm/drm_mode_config.h |  5 ++
 include/uapi/drm/drm_mode.h   |  7 +++
 7 files changed, 112 insertions(+), 5 deletions(-)

-- 
2.43.0

[PATCH v2 2/2] drm/amd: Add power_saving_policy drm property to eDP connectors

[Mario Limonciello]

When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.

When the `power_saving_policy` property is set to bit mask
"Require low latency" PSR should be disabled.

When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 3 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..cfb5220cf182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,10 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_power_saving_policy_property(adev_to_drm(adev),
+
DRM_MODE_POWER_SAVING_POLICY_ALL);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 01b0a331e4a6..a480e86892de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6421,6 +6421,13 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   dm_new_state->abm_forbidden = val & 
DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   dm_new_state->abm_level = (dm_new_state->abm_forbidden || 
!amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   dm_new_state->psr_forbidden = val & 
DRM_MODE_REQUIRE_LOW_LATENCY;
+   ret = 0;
}
 
return ret;
@@ -6463,6 +6470,13 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   *val = 0;
+   if (dm_state->psr_forbidden)
+   *val |= DRM_MODE_REQUIRE_LOW_LATENCY;
+   if (dm_state->abm_forbidden)
+   *val |= DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   ret = 0;
}
 
return ret;
@@ -6489,9 +6503,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6515,10 +6532,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7689,6 +7712,13 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
+   if (connector_type == DRM_MODE_CONNECTOR_eDP &&
+   

[PATCH v2 2/2] drm/amd: Add power_saving_policy drm property to eDP connectors

[Mario Limonciello]

When the `power_saving_policy` property is set to bit mask
"Require color accuracy" ABM should be disabled immediately and
any requests by sysfs to update will return an -EBUSY error.

When the `power_saving_policy` property is set to bit mask
"Require low latency" PSR should be disabled.

When the property is restored to an empty bit mask the previous
value of ABM and pSR will be restored.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 3 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
index 3ecc7ef95172..cfb5220cf182 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
@@ -1350,6 +1350,10 @@ int amdgpu_display_modeset_create_props(struct 
amdgpu_device *adev)
 "dither",
 amdgpu_dither_enum_list, sz);
 
+   if (adev->dc_enabled)
+   drm_mode_create_power_saving_policy_property(adev_to_drm(adev),
+
DRM_MODE_POWER_SAVING_POLICY_ALL);
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 01b0a331e4a6..a480e86892de 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6421,6 +6421,13 @@ int amdgpu_dm_connector_atomic_set_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
dm_new_state->underscan_enable = val;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   dm_new_state->abm_forbidden = val & 
DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   dm_new_state->abm_level = (dm_new_state->abm_forbidden || 
!amdgpu_dm_abm_level) ?
+   ABM_LEVEL_IMMEDIATE_DISABLE :
+   amdgpu_dm_abm_level;
+   dm_new_state->psr_forbidden = val & 
DRM_MODE_REQUIRE_LOW_LATENCY;
+   ret = 0;
}
 
return ret;
@@ -6463,6 +6470,13 @@ int amdgpu_dm_connector_atomic_get_property(struct 
drm_connector *connector,
} else if (property == adev->mode_info.underscan_property) {
*val = dm_state->underscan_enable;
ret = 0;
+   } else if (property == dev->mode_config.power_saving_policy) {
+   *val = 0;
+   if (dm_state->psr_forbidden)
+   *val |= DRM_MODE_REQUIRE_LOW_LATENCY;
+   if (dm_state->abm_forbidden)
+   *val |= DRM_MODE_REQUIRE_COLOR_ACCURACY;
+   ret = 0;
}
 
return ret;
@@ -6489,9 +6503,12 @@ static ssize_t panel_power_savings_show(struct device 
*device,
u8 val;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   val = to_dm_connector_state(connector->state)->abm_level ==
-   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
-   to_dm_connector_state(connector->state)->abm_level;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   val = 0;
+   else
+   val = to_dm_connector_state(connector->state)->abm_level ==
+   ABM_LEVEL_IMMEDIATE_DISABLE ? 0 :
+   to_dm_connector_state(connector->state)->abm_level;
drm_modeset_unlock(>mode_config.connection_mutex);
 
return sysfs_emit(buf, "%u\n", val);
@@ -6515,10 +6532,16 @@ static ssize_t panel_power_savings_store(struct device 
*device,
return -EINVAL;
 
drm_modeset_lock(>mode_config.connection_mutex, NULL);
-   to_dm_connector_state(connector->state)->abm_level = val ?:
-   ABM_LEVEL_IMMEDIATE_DISABLE;
+   if (to_dm_connector_state(connector->state)->abm_forbidden)
+   ret = -EBUSY;
+   else
+   to_dm_connector_state(connector->state)->abm_level = val ?:
+   ABM_LEVEL_IMMEDIATE_DISABLE;
drm_modeset_unlock(>mode_config.connection_mutex);
 
+   if (ret)
+   return ret;
+
drm_kms_helper_hotplug_event(dev);
 
return count;
@@ -7689,6 +7712,13 @@ void amdgpu_dm_connector_init_helper(struct 
amdgpu_display_manager *dm,
aconnector->base.state->max_bpc = 16;
aconnector->base.state->max_requested_bpc = 
aconnector->base.state->max_bpc;
 
+   if (connector_type == DRM_MODE_CONNECTOR_eDP &&
+   

[PATCH v2 1/2] drm: Introduce 'power saving policy' drm property

[Mario Limonciello]

The `power saving policy` DRM property is an optional property that
can be added to a connector by a driver.

This property is for compositors to indicate intent of policy of
whether a driver can use power saving features that may compromise
the experience intended by the compositor.

Signed-off-by: Mario Limonciello 
---
 drivers/gpu/drm/drm_connector.c | 46 +
 include/drm/drm_connector.h |  2 ++
 include/drm/drm_mode_config.h   |  5 
 include/uapi/drm/drm_mode.h |  7 +
 4 files changed, 60 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4d2df7f64dc5..088a5874c7a4 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -961,6 +961,11 @@ static const struct drm_prop_enum_list 
drm_scaling_mode_enum_list[] = {
{ DRM_MODE_SCALE_ASPECT, "Full aspect" },
 };
 
+static const struct drm_prop_enum_list drm_power_saving_policy_enum_list[] = {
+   { __builtin_ffs(DRM_MODE_REQUIRE_COLOR_ACCURACY) - 1, "Require color 
accuracy" },
+   { __builtin_ffs(DRM_MODE_REQUIRE_LOW_LATENCY) - 1, "Require low 
latency" },
+};
+
 static const struct drm_prop_enum_list drm_aspect_ratio_enum_list[] = {
{ DRM_MODE_PICTURE_ASPECT_NONE, "Automatic" },
{ DRM_MODE_PICTURE_ASPECT_4_3, "4:3" },
@@ -1499,6 +1504,16 @@ static const u32 dp_colorspaces =
  *
  * Drivers can set up these properties by calling
  * drm_mode_create_tv_margin_properties().
+ * power saving policy:
+ * This property is used to set the power saving policy for the connector.
+ * This property is populated with a bitmask of optional requirements set
+ * by the drm master for the drm driver to respect:
+ * - "Require color accuracy": Disable power saving features that will
+ *   affect color fidelity.
+ *   For example: Hardware assisted backlight modulation.
+ * - "Require low latency": Disable power saving features that will
+ *   affect latency.
+ *   For example: Panel self refresh (PSR)
  */
 
 int drm_connector_create_standard_properties(struct drm_device *dev)
@@ -1963,6 +1978,37 @@ int drm_mode_create_scaling_mode_property(struct 
drm_device *dev)
 }
 EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
 
+/**
+ * drm_mode_create_power_saving_policy_property - create power saving policy 
property
+ * @dev: DRM device
+ * @supported_policies: bitmask of supported power saving policies
+ *
+ * Called by a driver the first time it's needed, must be attached to desired
+ * connectors.
+ *
+ * Returns: %0
+ */
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies)
+{
+   struct drm_property *power_saving;
+
+   if (dev->mode_config.power_saving_policy)
+   return 0;
+   WARN_ON((supported_policies & DRM_MODE_POWER_SAVING_POLICY_ALL) == 0);
+
+   power_saving =
+   drm_property_create_bitmask(dev, 0, "power saving policy",
+   drm_power_saving_policy_enum_list,
+   
ARRAY_SIZE(drm_power_saving_policy_enum_list),
+   supported_policies);
+
+   dev->mode_config.power_saving_policy = power_saving;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_power_saving_policy_property);
+
 /**
  * DOC: Variable refresh properties
  *
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index fe88d7fc6b8f..b0ec2ec48de7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2025,6 +2025,8 @@ int drm_mode_create_dp_colorspace_property(struct 
drm_connector *connector,
   u32 supported_colorspaces);
 int drm_mode_create_content_type_property(struct drm_device *dev);
 int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
+int drm_mode_create_power_saving_policy_property(struct drm_device *dev,
+uint64_t supported_policies);
 
 int drm_connector_set_path_property(struct drm_connector *connector,
const char *path);
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 973119a9176b..32077e701e2f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -954,6 +954,11 @@ struct drm_mode_config {
 */
struct drm_atomic_state *suspend_state;
 
+   /**
+* @power_saving_policy: bitmask for power saving policy requests.
+*/
+   struct drm_property *power_saving_policy;
+
const struct drm_mode_config_helper_funcs *helper_private;
 };
 
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 7040e7ea80c7..c2c86623552c 100644
--- a/include/uapi/d

[PATCH v2 0/2] Add support for 'power saving policy' property

[Mario Limonciello]

During the Display Next hackfest 2024 one of the topics discussed
was the need for compositor to be able to relay intention to drivers
that color fidelity is preferred over power savings.

To accomplish this a new optional DRM property is being introduced called
"power saving policy".  This property is a bit mask that can be configured
with requests of "Require color accuracy" or "Require low latency"
that can be configured by the compositor.

When a driver advertises support for this property and the compositor
sets it to "Require color accuracy" then the driver will disable any power
saving features that can compromise color fidelity.

In practice the main feature this currently applies to is the
"Adaptive Backlight Modulation" feature within AMD DCN on eDP panels.

When the compositor has marked the property  "Require color accuracy" then
this feature will be disabled and any userspace that tries to turn it on
will get an -EBUSY return code.

Compositors can also request that low latency is critical which in practice
should cause PSR and PSR2 to be disabled.

When the compositor has restored the value back to no requirements then the
previous value that would have been programmed will be restored.

---
v1->v2:
 * New property as a bitmask
 * Handle both ABM and PSR/PSR2
 * Add documentation

Mario Limonciello (2):
  drm: Introduce 'power saving policy' drm property
  drm/amd: Add power_saving_policy drm property to eDP connectors

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c   |  4 ++
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 51 +--
 .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h |  2 +
 drivers/gpu/drm/drm_connector.c   | 46 +
 include/drm/drm_connector.h   |  2 +
 include/drm/drm_mode_config.h |  5 ++
 include/uapi/drm/drm_mode.h   |  7 +++
 7 files changed, 112 insertions(+), 5 deletions(-)

-- 
2.43.0

Re: Big Integers

[Mario Domenech Goulart]

Hi Doug,

On Tue, 21 May 2024 21:35:33 + (UTC) "T.D. Telford"  
wrote:

> Thanks for the reply.  The elapsed timings for the program rho3rec are:
>
> chicken 5.3.0:  33.6 seconds
> Racket v8.2 [cs]  : 18.1 seconds
> Dr Racket : 20.6 seconds  (1 MB memory)
>
> The program uses the Pollard rho algorithm to find a factor of 2^257 -1.  The 
> program is highly recursive, but I have a
> non recursive version that has the same timing as the above.  I am using an 
> AMD Ryzen 5600 cpu and 32 GB of main memory.
>
> I tried all of the csc options that appeared related to speed, and the 
> maximum improvement was 0.1 seconds. 
>
> The one option I did not get to work was
> -heap-size 1000M
> where I varied the size from 1000M to 1M.  In all cases I would get the 
> run time message
> [panic] out of memory - heap full - execution terminated
>
> I have include the program listing below and also as an attachment.
>
> Regards,
> Doug
>
> ;;;
> ;;#lang racket;; uncomment for racket
>
> (define (rho n u v c iter prod)
>   (let* ( [u1 (modulo (+ (* u u) c) n)]
>   [v1 (modulo (+ (* v v) c) n)]
>   [v2 (modulo (+ (* v1 v1) c) n)]
>   [done #f]
>   [max_iter 3000]
>   [iter2 (+ iter 1)]
>   [prod2 (modulo (* prod (- u1 v2)) n)] )
>
> (if (= (modulo iter2 150) 0)
>   (begin; modulo true
> (let ( [g (gcd prod2 n) ] )
>   (if (and (> g 1) (< g n))
> (begin ; factor
>   (display "factor = ") (display g) (newline)
>   (display "iterations = ") (display iter2) (newline)
>   (set! done #t)
> )
> (set! prod2 1) ; no factor
>   ) ; end if factor
> ) ; end let 
>   ) ; end begin for modulo true
>   #f ;action for modulo false
> ) ; end major if
>
> (if (and (< iter2 max_iter) (not done)) 
>   (rho n u1 v2 c iter2 prod2)
>   (if done ; either found factor or max iterations
> (display "normal termination \n")
> #f
>   ) ; if done
> ) ; if and 
>   ) ; end let*
> )
>
> (let ( [n (- (expt 2 257) 1)] [u 2] [v 11] [c 7] [iter 1] [prod 1] )
> (display "factor n = ") (display n) (newline)
> (time (rho n u v c iter prod))
> )
>
> ;;;

Thanks for providing the program.

Would it be ok to add it as a benchmark program to
https://github.com/mario-goulart/chicken-benchmarks?

All the best.
Mario
-- 
http://parenteses.org/mario

Re: [PATCH v2] drm/amd/display: Add pixel encoding info to debugfs

[Mario Limonciello]

+ Simon

On 5/22/2024 05:07, Rino André Johnsen wrote:

To be perfectly honest with you, I haven't given that much though. I
used the 'bpc' and 'colorspace' property in debugfs, since I could not
find that information anywhere else. And since I also needed to verify
the pixel encoding being used, I added it where those other values
were. That made for a simple and easy addition for this property.

If you want me to do this differently, let me know. And please point
me to the standardized DRM property where I should expose the values.


Here's a pointer to where the colorspace property is created:

https://github.com/torvalds/linux/blob/v6.9/drivers/gpu/drm/drm_connector.c#L2147

I would expect you can make another property for the information you're 
looking for and then can get it from userspace using standard property

APIs.



Rino

On Tue, May 21, 2024 at 10:55 PM Mario Limonciello
 wrote:


On 5/21/2024 15:06, Rino André Johnsen wrote:

What is already there in debugfs is 'bpc' and 'colorspace', but not
the pixel encoding/format.
I have searched high and low for that to be able to verify that my
monitor and computer are using my preferred combination of all those
three values.

I do think it should be available as a standard DRM CRTC property, but
for the time being, I figured that a simple debugfs property would be
sufficient for time being.



It's just about as much work either way to populate it though, why do it
twice instead of just doing it right the first time?


Rino


On Tue, May 21, 2024 at 9:04 PM Christian König
 wrote:


Am 21.05.24 um 07:11 schrieb Rino Andre Johnsen:

[Why]
For debugging and testing purposes.

[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding


Why isn't that available as standard DRM CRTC property in either sysfs
or debugfs?

I think the format specifiers should already be available somewhere there.

Regards,
Christian.



Signed-off-by: Rino Andre Johnsen 
---

Changes in v2:
1. Do not initialize dm_crtc_state to NULL.
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 47 +++
1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 27d5c6077630..4254d4a4b56b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1160,6 +1160,51 @@ static int amdgpu_current_colorspace_show(struct 
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);

+/*
+ * Returns the current pixelencoding for the crtc.
+ * Example usage: cat 
/sys/kernel/debug/dri/0/crtc-0/amdgpu_current_pixelencoding
+ */
+static int amdgpu_current_pixelencoding_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->timing.pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ seq_puts(m, "RGB");
+ break;
+ case PIXEL_ENCODING_YCBCR422:
+ seq_puts(m, "YCBCR422");
+ break;
+ case PIXEL_ENCODING_YCBCR444:
+ seq_puts(m, "YCBCR444");
+ break;
+ case PIXEL_ENCODING_YCBCR420:
+ seq_puts(m, "YCBCR420");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_pixelencoding);

/*
 * Example usage:
@@ -3688,6 +3733,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
crtc, _current_bpc_fops);
debugfs_create_file("amdgpu_current_colorspace", 0644, 
crtc->debugfs_entry,
crtc, _current_colorspace_fops);
+ debugfs_create_file("amdgpu_current_pixelencoding", 0644, 
crtc->debugfs_entry,
+ crtc, _current_pixelencoding_fops);
}

/*

Re: [PATCH v2] drm/amd/display: Add pixel encoding info to debugfs

[Mario Limonciello]

+ Simon

On 5/22/2024 05:07, Rino André Johnsen wrote:

To be perfectly honest with you, I haven't given that much though. I
used the 'bpc' and 'colorspace' property in debugfs, since I could not
find that information anywhere else. And since I also needed to verify
the pixel encoding being used, I added it where those other values
were. That made for a simple and easy addition for this property.

If you want me to do this differently, let me know. And please point
me to the standardized DRM property where I should expose the values.


Here's a pointer to where the colorspace property is created:

https://github.com/torvalds/linux/blob/v6.9/drivers/gpu/drm/drm_connector.c#L2147

I would expect you can make another property for the information you're 
looking for and then can get it from userspace using standard property

APIs.



Rino

On Tue, May 21, 2024 at 10:55 PM Mario Limonciello
 wrote:


On 5/21/2024 15:06, Rino André Johnsen wrote:

What is already there in debugfs is 'bpc' and 'colorspace', but not
the pixel encoding/format.
I have searched high and low for that to be able to verify that my
monitor and computer are using my preferred combination of all those
three values.

I do think it should be available as a standard DRM CRTC property, but
for the time being, I figured that a simple debugfs property would be
sufficient for time being.



It's just about as much work either way to populate it though, why do it
twice instead of just doing it right the first time?


Rino


On Tue, May 21, 2024 at 9:04 PM Christian König
 wrote:


Am 21.05.24 um 07:11 schrieb Rino Andre Johnsen:

[Why]
For debugging and testing purposes.

[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding


Why isn't that available as standard DRM CRTC property in either sysfs
or debugfs?

I think the format specifiers should already be available somewhere there.

Regards,
Christian.



Signed-off-by: Rino Andre Johnsen 
---

Changes in v2:
1. Do not initialize dm_crtc_state to NULL.
---
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 47 +++
1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 27d5c6077630..4254d4a4b56b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1160,6 +1160,51 @@ static int amdgpu_current_colorspace_show(struct 
seq_file *m, void *data)
}
DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);

+/*
+ * Returns the current pixelencoding for the crtc.
+ * Example usage: cat 
/sys/kernel/debug/dri/0/crtc-0/amdgpu_current_pixelencoding
+ */
+static int amdgpu_current_pixelencoding_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->timing.pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ seq_puts(m, "RGB");
+ break;
+ case PIXEL_ENCODING_YCBCR422:
+ seq_puts(m, "YCBCR422");
+ break;
+ case PIXEL_ENCODING_YCBCR444:
+ seq_puts(m, "YCBCR444");
+ break;
+ case PIXEL_ENCODING_YCBCR420:
+ seq_puts(m, "YCBCR420");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_pixelencoding);

/*
 * Example usage:
@@ -3688,6 +3733,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
crtc, _current_bpc_fops);
debugfs_create_file("amdgpu_current_colorspace", 0644, 
crtc->debugfs_entry,
crtc, _current_colorspace_fops);
+ debugfs_create_file("amdgpu_current_pixelencoding", 0644, 
crtc->debugfs_entry,
+ crtc, _current_pixelencoding_fops);
}

/*

[docker-dev] @!!#MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba #butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart #k2prisonsheets #cannabis #cannabinoids #benzos

[mario winners]

 #MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba 
#butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart 
#k2prisonsheets #cannabis #cannabinoids #benzos #etizolam #fentanyl

✅ Buy 5CL-ADB-A powder online

Telegram: https://t.me/syntheticbutinaca
Telegram chat @synthetic_butinaca

https://chemniac.com/product/buy-5cl-adb-a-powder-online/

-- 
You received this message because you are subscribed to the Google Groups 
"docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to docker-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/docker-dev/139a4acd-db1e-4d33-b70f-0210fd3bd82bn%40googlegroups.com.

[docker-dev] !~!#MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba #butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart #k2prisonsheets #cannabis #cannabinoids #benzos

[mario winners]

 #MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba 
#butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart 
#k2prisonsheets #cannabis #cannabinoids #benzos #etizolam #fentanyl

✅ Buy 5CL-ADB-A powder online

Telegram: https://t.me/syntheticbutinaca
Telegram chat @synthetic_butinaca

https://chemniac.com/product/buy-5cl-adb-a-powder-online/

-- 
You received this message because you are subscribed to the Google Groups 
"docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to docker-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/docker-dev/08f283b8-f88d-4afc-8594-f6b4ff7d51f0n%40googlegroups.com.

[docker-dev] #MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba #butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart #k2prisonsheets #cannabis #cannabinoids #benzos #et

[mario winners]

#MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba 
#butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart 
#k2prisonsheets #cannabis #cannabinoids #benzos #etizolam #fentanyl

✅ Buy 5CL-ADB-A powder online

Telegram: https://t.me/syntheticbutinaca
Telegram chat @synthetic_butinaca

https://chemniac.com/product/buy-5cl-adb-a-powder-online/

-- 
You received this message because you are subscribed to the Google Groups 
"docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to docker-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/docker-dev/27696e03-8cbb-48b0-a937-6772e9e0a436n%40googlegroups.com.

[docker-dev] #MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba #butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart #k2prisonsheets #cannabis #cannabinoids #benzos #et

[mario winners]

#MDMA #3MMC #Ecstacy #JWH #Alprazolam #4mmc #cocaine #eutylone #5cladba 
#butinaca ADB #6cladba #ketamine #k2sheets #k2spicespraywalmart 
#k2prisonsheets #cannabis #cannabinoids #benzos #etizolam #fentanyl

✅ Buy 5CL-ADB-A powder online

Telegram: https://t.me/syntheticbutinaca
Telegram chat @synthetic_butinaca

https://chemniac.com/product/buy-5cl-adb-a-powder-online/

-- 
You received this message because you are subscribed to the Google Groups 
"docker-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to docker-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/docker-dev/84804713-9a3b-475f-9bbc-fc0f1493e5aen%40googlegroups.com.

Re: [PATCH v2] drm/amd/display: Add pixel encoding info to debugfs

[Mario Limonciello]

On 5/21/2024 15:06, Rino André Johnsen wrote:

What is already there in debugfs is 'bpc' and 'colorspace', but not
the pixel encoding/format.
I have searched high and low for that to be able to verify that my
monitor and computer are using my preferred combination of all those
three values.

I do think it should be available as a standard DRM CRTC property, but
for the time being, I figured that a simple debugfs property would be
sufficient for time being.



It's just about as much work either way to populate it though, why do it 
twice instead of just doing it right the first time?



Rino


On Tue, May 21, 2024 at 9:04 PM Christian König
 wrote:


Am 21.05.24 um 07:11 schrieb Rino Andre Johnsen:

[Why]
For debugging and testing purposes.

[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding


Why isn't that available as standard DRM CRTC property in either sysfs
or debugfs?

I think the format specifiers should already be available somewhere there.

Regards,
Christian.



Signed-off-by: Rino Andre Johnsen 
---

Changes in v2:
1. Do not initialize dm_crtc_state to NULL.
---
   .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 47 +++
   1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 27d5c6077630..4254d4a4b56b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1160,6 +1160,51 @@ static int amdgpu_current_colorspace_show(struct 
seq_file *m, void *data)
   }
   DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);

+/*
+ * Returns the current pixelencoding for the crtc.
+ * Example usage: cat 
/sys/kernel/debug/dri/0/crtc-0/amdgpu_current_pixelencoding
+ */
+static int amdgpu_current_pixelencoding_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->timing.pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ seq_puts(m, "RGB");
+ break;
+ case PIXEL_ENCODING_YCBCR422:
+ seq_puts(m, "YCBCR422");
+ break;
+ case PIXEL_ENCODING_YCBCR444:
+ seq_puts(m, "YCBCR444");
+ break;
+ case PIXEL_ENCODING_YCBCR420:
+ seq_puts(m, "YCBCR420");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_pixelencoding);

   /*
* Example usage:
@@ -3688,6 +3733,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
   crtc, _current_bpc_fops);
   debugfs_create_file("amdgpu_current_colorspace", 0644, 
crtc->debugfs_entry,
   crtc, _current_colorspace_fops);
+ debugfs_create_file("amdgpu_current_pixelencoding", 0644, 
crtc->debugfs_entry,
+ crtc, _current_pixelencoding_fops);
   }

   /*

Re: [PATCH v2] drm/amd/display: Add pixel encoding info to debugfs

[Mario Limonciello]

On 5/21/2024 15:06, Rino André Johnsen wrote:

What is already there in debugfs is 'bpc' and 'colorspace', but not
the pixel encoding/format.
I have searched high and low for that to be able to verify that my
monitor and computer are using my preferred combination of all those
three values.

I do think it should be available as a standard DRM CRTC property, but
for the time being, I figured that a simple debugfs property would be
sufficient for time being.



It's just about as much work either way to populate it though, why do it 
twice instead of just doing it right the first time?



Rino


On Tue, May 21, 2024 at 9:04 PM Christian König
 wrote:


Am 21.05.24 um 07:11 schrieb Rino Andre Johnsen:

[Why]
For debugging and testing purposes.

[How]
Create amdgpu_current_pixelencoding debugfs entry.
Usage: cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_pixelencoding


Why isn't that available as standard DRM CRTC property in either sysfs
or debugfs?

I think the format specifiers should already be available somewhere there.

Regards,
Christian.



Signed-off-by: Rino Andre Johnsen 
---

Changes in v2:
1. Do not initialize dm_crtc_state to NULL.
---
   .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 47 +++
   1 file changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index 27d5c6077630..4254d4a4b56b 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -1160,6 +1160,51 @@ static int amdgpu_current_colorspace_show(struct 
seq_file *m, void *data)
   }
   DEFINE_SHOW_ATTRIBUTE(amdgpu_current_colorspace);

+/*
+ * Returns the current pixelencoding for the crtc.
+ * Example usage: cat 
/sys/kernel/debug/dri/0/crtc-0/amdgpu_current_pixelencoding
+ */
+static int amdgpu_current_pixelencoding_show(struct seq_file *m, void *data)
+{
+ struct drm_crtc *crtc = m->private;
+ struct drm_device *dev = crtc->dev;
+ struct dm_crtc_state *dm_crtc_state;
+ int res = -ENODEV;
+
+ mutex_lock(>mode_config.mutex);
+ drm_modeset_lock(>mutex, NULL);
+ if (crtc->state == NULL)
+ goto unlock;
+
+ dm_crtc_state = to_dm_crtc_state(crtc->state);
+ if (dm_crtc_state->stream == NULL)
+ goto unlock;
+
+ switch (dm_crtc_state->stream->timing.pixel_encoding) {
+ case PIXEL_ENCODING_RGB:
+ seq_puts(m, "RGB");
+ break;
+ case PIXEL_ENCODING_YCBCR422:
+ seq_puts(m, "YCBCR422");
+ break;
+ case PIXEL_ENCODING_YCBCR444:
+ seq_puts(m, "YCBCR444");
+ break;
+ case PIXEL_ENCODING_YCBCR420:
+ seq_puts(m, "YCBCR420");
+ break;
+ default:
+ goto unlock;
+ }
+ res = 0;
+
+unlock:
+ drm_modeset_unlock(>mutex);
+ mutex_unlock(>mode_config.mutex);
+
+ return res;
+}
+DEFINE_SHOW_ATTRIBUTE(amdgpu_current_pixelencoding);

   /*
* Example usage:
@@ -3688,6 +3733,8 @@ void crtc_debugfs_init(struct drm_crtc *crtc)
   crtc, _current_bpc_fops);
   debugfs_create_file("amdgpu_current_colorspace", 0644, 
crtc->debugfs_entry,
   crtc, _current_colorspace_fops);
+ debugfs_create_file("amdgpu_current_pixelencoding", 0644, 
crtc->debugfs_entry,
+ crtc, _current_pixelencoding_fops);
   }

   /*

[Bug 2063002] Re: Add support for DCN 3.5

[Mario Limonciello]

As the firmware is on it's own stable and by the time this hardware is
in market that kernel fix should be picked up adding verification done
tag.

** Tags added: verification-done-noble

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2063002

Title:
  Add support for DCN 3.5

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/2063002/+subscriptions


-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs