from:"Hector"

Also reported here:
https://github.com/mate-desktop/mate-calc/issues/205#issue-1077895579

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

Title:
  Financial mode incorrectly places currency for Russian Rouble

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-calc/+bug/1955350/+subscriptions


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

[Bug 1955350] [NEW] Financial mode incorrectly places currency for Russian Rouble

Public bug reported:

Open mate-calc, switch to Financial mode, select Russian Rouble from
drop-down menu below.

Expected behaviour - Russian Rouble currency must be placed AFTER the
value, not before.

# Russian Rouble <> USD

1000 руб. = $13.59
USD <> Russian Rouble

$10 = 736,06 руб.

# Actual behaviour now:

Russian Rouble <> USD

руб. 1000 = $13.59
USD <> Russian Rouble

$10 = руб. 736,06

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: mate-calc 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 23:02:03 2021
InstallationDate: Installed on 2021-12-15 (4 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: mate-calc
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mate-calc (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/mate-calc/issues #205
   https://github.com/mate-desktop/mate-calc/issues/205

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

Title:
  Financial mode incorrectly places currency for Russian Rouble

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-calc/+bug/1955350/+subscriptions


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

[Bug 1955348] Re: File Properties dialog barely fits into display in width under Russian localization

Also reported here:
https://github.com/mate-desktop/caja/issues/1592

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

Title:
  File Properties dialog barely fits into display in width under Russian
  localization

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


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

[Bug 1955348] [NEW] File Properties dialog barely fits into display in width under Russian localization

Public bug reported:

In Russian localization ru_RU.
But could be reproduced in other non-English vocalizations as well.

Open caja, right click on a file and watch tabs of the dialog.dialog are

This file "Properties" dialog (RU: "Свойства архива") displays all possible 
tabs in one wide line requiring more than 1550px of width to render the dialog. 
Under certain display resolutions utmost left and right sides of the dialog are 
not visible.


All dialog's tabs must be visible and easily accessible under any display 
resolutions.
If dialog's width exceeds an accepted threshold, ideally the tabs should be 
presented in stackable form.
This will allow users seeing all possible tabs/actions.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: caja 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 22:23:50 2021
InstallationDate: Installed on 2021-12-15 (4 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: caja
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: caja (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/caja/issues #1592
   https://github.com/mate-desktop/caja/issues/1592

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

Title:
  File Properties dialog barely fits into display in width under Russian
  localization

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


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

[Bug 1955343] [NEW] Atril does not zoom in/out epub documents

Public bug reported:

Expected behaviour:

Menu provides options to zoom to "Fit page", "Fit width", "50%", "100%",
"150%". They must be handled for epub files as well.


Actual behaviour:

Atril ignores all attempts to zoom to "Fit page", "Fit width", "50%", or
any other requested variants on epub documents.

JFYI: PDF files are treated as expected, PDF files can be properly
zoomed to any value.

Steps to reproduce the behaviour"

Open an epub document with Atril application. Try choosing "Fit width",
"50%", "100%", "150%".

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: atril 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 17:05:11 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: atril
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: atril (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/atril/issues #553
   https://github.com/mate-desktop/atril/issues/553

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

Title:
  Atril does not zoom in/out epub documents

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


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

[Bug 1955343] Re: Atril does not zoom in/out epub documents

Also reported here:
https://github.com/mate-desktop/atril/issues/553

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

Title:
  Atril does not zoom in/out epub documents

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


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

[Bug 1955341] Re: EOM puts wrong file name on "Save As..."

Also reported here:
https://github.com/mate-desktop/eom/issues/329

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

Title:
  EOM puts wrong file name on "Save As..."

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


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

[Bug 1955341] [NEW] EOM puts wrong file name on "Save As..."

Public bug reported:

Expected behaviour:
Original file name must be preserved in the field "Name:".

Actual behaviour
Random file name is suggested the field "Name:" after attempting to select 
desired file extension.

Steps to reproduce the behaviour

Organize a folder with several graphical files like below:

file1.png
file2.png
file3.png
file4.png
file5.png

Double click on one of them, for instance, click on file3.png to open it in 
application "Eye of MATE".
Try saving this file with menu "Image", "Save As...".
A dialog titled "Save Image" opens.
In bottom right corner of this dialog choose specific file type (extension), 
e.g. "JPEG (*.jpeg)".
Watch different file name has been substituted in the upper field "Name:".

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: eom 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 16:53:11 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: eom
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: eom (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/eom/issues #329
   https://github.com/mate-desktop/eom/issues/329

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

Title:
  EOM puts wrong file name on "Save As..."

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


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

[Bug 1955340] [NEW] Cannot remove 'Background picture for lock screen:'

Public bug reported:

Open dialog "Screensaver Preferences". Click on "Background picture for lock 
screen:", select a file.
Once a file has been selected, there are no obvious ways of removing that file 
name.

There must be some way of removing previously chosen file
in the field "Background picture for lock screen:'"
dialog "Screensaver Preferences".

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: mate-screensaver 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 16:38:04 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: mate-screensaver
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mate-screensaver (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/mate-screensaver/issues #269
   https://github.com/mate-desktop/mate-screensaver/issues/269

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

Title:
   Cannot remove 'Background picture for lock screen:'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-screensaver/+bug/1955340/+subscriptions


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

[Bug 1955340] Re: Cannot remove 'Background picture for lock screen:'

Also reported here:
https://github.com/mate-desktop/mate-screensaver/issues/269

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

Title:
   Cannot remove 'Background picture for lock screen:'

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-screensaver/+bug/1955340/+subscriptions


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

[Bug 1955339] [NEW] mate-time-admin: 'Lock' button does not take effect

Public bug reported:

Menu, "Control center", "Hardware", "Time and Date Manager".
Try clicking the button 'Lock'.
Regardless of how many times it is clicked, the button always shows "Lock" and 
its text says "Dialog is unlocked".

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: mate-control-center 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 16:32:30 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: mate-control-center
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mate-control-center (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/mate-control-center/issues #561
   https://github.com/mate-desktop/mate-control-center/issues/561

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

Title:
  mate-time-admin: 'Lock' button does not take effect

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1955339/+subscriptions


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

[Bug 1955339] Re: mate-time-admin: 'Lock' button does not take effect

Also reported here:
https://github.com/mate-desktop/mate-control-center/issues/561

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

Title:
  mate-time-admin: 'Lock' button does not take effect

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-control-center/+bug/1955339/+subscriptions


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

[Bug 1955335] Re: clock-applet doesn't contain majority of Russian cities

Also reported here:
https://github.com/mate-desktop/mate-panel/issues/1285


** Bug watch added: github.com/mate-desktop/mate-panel/issues #1285
   https://github.com/mate-desktop/mate-panel/issues/1285

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

Title:
   clock-applet doesn't contain majority of Russian cities

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-panel/+bug/1955335/+subscriptions


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

[Bug 1955336] Re: mate-volume-control: Speaker testing dialog changes size on pressing "Test" in Russian localization

Also reported here: 
https://github.com/mate-desktop/mate-control-center/issues/685

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

Title:
  mate-volume-control: Speaker testing dialog changes size on pressing
  "Test" in Russian localization

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-media/+bug/1955336/+subscriptions


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

[Bug 1955336] [NEW] mate-volume-control: Speaker testing dialog changes size on pressing "Test" in Russian localization

Public bug reported:

When "Test" button is pressed (RU: "Проверить"), the window "Speaker
testing" (RU: "Проверка динамиков") becomes wider.

Steps to reproduce the behaviour:

In Russian localization "ru_RU".
Start mate-volume-control, click on "Hardware" tab (RU: "Оборудование"), then 
on the "Test Speakers" button (RU: "Проверить динамики") below. Click on "Test" 
buttons in the new dialog to watch the symptom.
This is not reproduced in English localization.

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: mate-media 1.26.0-0ubuntu1
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 15:45:10 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: mate-media
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mate-media (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

** Bug watch added: github.com/mate-desktop/mate-control-center/issues #685
   https://github.com/mate-desktop/mate-control-center/issues/685

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

Title:
  mate-volume-control: Speaker testing dialog changes size on pressing
  "Test" in Russian localization

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-media/+bug/1955336/+subscriptions


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

[Bug 1955335] [NEW] clock-applet doesn't contain majority of Russian cities

Public bug reported:

"Clock Preferences" -> "Location" -> "Choose Location"

All regional capitals and other major cities must be included into the
list of Russian locations. Here is the list of missing locations:

Arzamas (RU: "Арзамас")
Armavir (RU: "Армавир")
Achinsk (RU: "Ачинск")
Belgorod (RU: "Белгород")
Biysk (RU: "Бийск")
Blagoveschensk (RU: "Благовещенск")
Birobidzhan (RU: "Биробиджан")
Vanino (RU: "Ванино")
Velikiy Novgorod (RU: "Великий Новгород")
Velikiy Ustyug (RU: "Великий Устюг")
Vladimir (RU: "Владимир")
Vladikavkaz (RU: "Владикавказ")
Volgodonsk (RU: "Волгодонск")
Vorkuta (RU: "Воркута")
Vyborg (RU: "Выборг")
Vyksa (RU: "Выкса")
Vyshny Volochyok (RU: "Вышний Волочёк")
Vyazma (RU: "Вязьма")
Gelendzhik (RU: "Геленджик")
Gorno-Altaysk (RU: "Горно-Алтайск")
Gorodets (RU: "Городец")
Grozny (RU: "Грозный")
Gus-Khrustalny (RU: "Гусь-Хрустальный")
Derbent (RU: "Дербент")
Dimitrovgrad (RU: "Димитровград")
Dubna (RU: "Дубна")
Yelabuga (RU: "Елабуга")
Yelets (RU: "Елец")
Yessentuki (RU: "Ессентуки")
Zheleznogorsk (RU: "Железногорск")
Zavolzhye (RU: "Заволжье")
Ivanovo (RU: "Иваново")
Igarka (RU: "Игарка")
Izhevsk (RU: "Ижевск")
Yoshkar-Ola (RU: "Йошкар-Ола")
Kamyshin (RU: "Камышин")
Kasimov (RU: "Касимов")
Kaluga (RU: "Калуга")
Kizlyar (RU: "Кизляр")
Kineshma (RU: "Кинешма")
Kirov (RU: "Киров")
Kirovo-Chepetsk (RU: "Кирово-Чепецк")
Kislovodsk (RU: "Кисловодск")
Kolomna (RU: "Коломна")
Kovrov (RU: "Ковров")
Kogalym (RU: "Когалым)
Kostroma (RU: "Кострома")
Kotlas (RU: "Котлас")
Komsomolsk-on-Amur (RU: "Комсомольск-на-Амуре")
Kurgan (RU: "Курган")
Kyzyl (RU: "Кызыл")
Lipetsk (RU: "Липецк")
Magnitogorsk (RU: "Магнитогорск")
Maykop (RU: "Майкоп")
Makhachkala (RU: "Махачкала")
Miass (RU: "Миасс")
Minusinsk (RU: "Минусинск")
Magas (RU: "Магас")
Mozdok (RU: "Моздок)
Murom (RU: "Муром")
Nadym (RU: "Надым")
Nakhodka (RU: "Находка")
Naryan-Mar (RU: "Нарьян-Мар")
Naberezhnye Chelny (RU: "Набережные Челны")
Nerekhta (RU: "Нерехта")
Nefteyugansk (RU: "Нефтеюганск")
Nizhnekamsk (RU: "Нижнекамск")
Nizhny Novgorod (RU: "Нижний Новгород")
Nizhniy Tagil (RU: "Нижний Тагил")
Novorossiysk (RU: "Новороссийск")
Noviy Urengoy (RU: "Новый Уренгой")
Norilsk (RU: "Норильск")
Oryol (RU: "Орёл")
Orsk (RU: "Орск")
Okha (RU: "Оха")
Pereslavl-Zalessky (RU: "Переславль-Залесский")
Petrozavodsk (RU: "Петрозаводск")
Pechory (RU: "Печоры")
Pskov (RU: "Псков")
Pyatigorsk (RU: "Пятигорск")
Rubtsovsk (RU: "Рубцовск")
Rybinsk (RU: "Рыбинск")
Salekhard (RU: "Салехард")
Sarov (RU: "Саров")
Saransk (RU: "Саранск")
Severodvinsk (RU: "Северодвинск")
Smolensk (RU: "Смоленск")
Solikamsk (RU: "Соликамск")
Sovetskaya Gavan (RU: "Советская Гавань")
Sochi (RU: "Сочи")
Staryy Oskol (RU: "Старый Оскол")
Sterlitamak (RU: "Стерлитамак")
Syzran (RU: "Сызрань")
Taganrog (RU: "Таганрог")
Tambov (RU: "Тамбов")
Tobolsk (RU: "Тобольск")
Tolyatti (RU: "Тольятти")
Tver (RU: "Тверь")
Tuapse (RU: "Туапсе")
Tula (RU: "Тула")
Tynda (RU: "Тында")
Ussuriysk (RU: "Уссурийск")
Ukhta (RU: "Ухта")
Cheboksary (RU: "Чебоксары")
Cherepovets (RU: "Череповец")
Cherkessk (RU: "Черкесск")
Chusovoy (RU: "Чусовой")
Shakhty (RU: "Шахты")
Shuya (RU: "Шуя")
Elista (RU: "Элиста")
Yuzhno-Kurilsk (RU: "Южно-Курильск")
Yaroslavl (RU: "Ярославль")

ProblemType: Bug
DistroRelease: Ubuntu 21.10
Package: mate-panel 1.26.0-0ubuntu3
ProcVersionSignature: Ubuntu 5.13.0-22.22-generic 5.13.19
Uname: Linux 5.13.0-22-generic x86_64
ApportVersion: 2.20.11-0ubuntu71
Architecture: amd64
CasperMD5CheckResult: pass
CurrentDesktop: MATE
Date: Sun Dec 19 15:39:24 2021
InstallationDate: Installed on 2021-12-15 (3 days ago)
InstallationMedia: Ubuntu-MATE 21.10 "Impish Indri" - Release amd64 (20211012)
SourcePackage: mate-panel
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: mate-panel (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug impish

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

Title:
   clock-applet doesn't contain majority of Russian cities

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/mate-panel/+bug/1955335/+subscriptions


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

[jenkinsci/nexus-platform-plugin]

2021-12-16 Thread 'Hector Danilo Hurtado Olaya' via Jenkins Commits

  Branch: refs/heads/INT-5615-updating-release-notes-for-nuget-bug
  Home:   https://github.com/jenkinsci/nexus-platform-plugin

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/nexus-platform-plugin/push/refs/heads/INT-5615-updating-release-notes-for-nuget-bug/3e60f3-00%40github.com.

[jenkinsci/nexus-platform-plugin] 3e60f3: Updating release notes

2021-12-16 Thread 'Hector Danilo Hurtado Olaya' via Jenkins Commits

  Branch: refs/heads/main
  Home:   https://github.com/jenkinsci/nexus-platform-plugin
  Commit: 3e60f3fd7db705a78ebdbc1de17ad6be0e1c3ec6
  
https://github.com/jenkinsci/nexus-platform-plugin/commit/3e60f3fd7db705a78ebdbc1de17ad6be0e1c3ec6
  Author: Hector Hurtado 
  Date:   2021-12-16 (Thu, 16 Dec 2021)

  Changed paths:
M README.md

  Log Message:
  ---
  Updating release notes


  Commit: 3c2aa7a13c77139e7a6bda5c3d0276e78c284002
  
https://github.com/jenkinsci/nexus-platform-plugin/commit/3c2aa7a13c77139e7a6bda5c3d0276e78c284002
  Author: Hector Danilo Hurtado Olaya 
  Date:   2021-12-16 (Thu, 16 Dec 2021)

  Changed paths:
M README.md

  Log Message:
  ---
  Merge pull request #171 from 
jenkinsci/INT-5615-updating-release-notes-for-nuget-bug

INT-5615 Updating release notes


Compare: 
https://github.com/jenkinsci/nexus-platform-plugin/compare/f1ef3f90738c...3c2aa7a13c77

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/nexus-platform-plugin/push/refs/heads/main/f1ef3f-3c2aa7%40github.com.

[jenkinsci/nexus-platform-plugin] 3e60f3: Updating release notes

2021-12-16 Thread 'Hector Danilo Hurtado Olaya' via Jenkins Commits

  Branch: refs/heads/INT-5615-updating-release-notes-for-nuget-bug
  Home:   https://github.com/jenkinsci/nexus-platform-plugin
  Commit: 3e60f3fd7db705a78ebdbc1de17ad6be0e1c3ec6
  
https://github.com/jenkinsci/nexus-platform-plugin/commit/3e60f3fd7db705a78ebdbc1de17ad6be0e1c3ec6
  Author: Hector Hurtado 
  Date:   2021-12-16 (Thu, 16 Dec 2021)

  Changed paths:
M README.md

  Log Message:
  ---
  Updating release notes


-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Commits" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-commits+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-commits/jenkinsci/nexus-platform-plugin/push/refs/heads/INT-5615-updating-release-notes-for-nuget-bug/00-3e60f3%40github.com.

Re: [Koha] difficulties authenticating after samba/openldap -> samba4 AD migration with koha

2021-12-13 Thread Hector Gonzalez Jaime


Try removing id="dc1" from the ldapserver line, so it looks like this:




On 12/12/21 10:53 AM, Web Developer wrote:

help me to solve this.

On Sat, 11 Dec 2021 at 22:23, Web Developer  wrote:


Hello Team,


I am trying to authenticate samba4/AD to koha LDAP but I am getting the
following error.


However, I can't login, koha OPAC log says  : LDAP search failed to return
object : 2020: Operation unavailable without authentication at
/usr/share/test_koha/lib/C4/Auth_with_ldap.pm line 98.


So, before I start doing bigger things (like updating koha, which has
always been running fine) I'd like to know if I'm missing something
obvious? I'm sure many people here are using (native) active directory
to authenticate to? Any tips..?

Here is my AD samba4 config:

   
  dc1.my.domain
  CN=Users,DC=samba,DC=my,DC=domain
  username
 password

  1
  1
  1

CN=%s,CN=Users,DC=samba,DC=my,DC=domain

  


  


Regards,
Amar


___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha


--
Hector Gonzalez
ca...@genac.org

___

Koha mailing list  http://koha-community.org
Koha@lists.katipo.co.nz
Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha

Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

2021-12-13 Thread Hector Geraldino (BLOOMBERG/ 919 3RD A)

Hi kafka-devs,

I would like a second review to the proposed changes on KIP-795: Add public 
APIs for AbstractCoordinator 
[ 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-795%3A+Add+public+APIs+for
+AbstractCoordinator ]

I've amended the KIP addressing Tom's feedback, and also opened a PR with the 
proposed changes [ https://github.com/apache/kafka/pull/11515 ]. There's also a 
PR for the kafka-monitor tool [ 
https://github.com/linkedin/kafka-monitor/pull/355 ] that demonstrates how we 
leveraged  AbstractCoordinator to implement a High-Availability mode for it, 
with the intention of showing how this feature can be leveraged by other 
services within the Kafka ecosystem and outside it.

Thanks for your time and consideration.
Hector
 
From: dev@kafka.apache.org At: 11/29/21 13:31:26 UTC-5:00To:  
dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hello again Tom, kafka devs

First, congrats on becoming a PMC member! That's so cool.

Since your last reply I've updated the KIP trying to address some of your 
suggestions. A few more details have been added to the motivation section, and 
also went ahead and opened a draft pull-request with the changes I think are 
needed for this KIP, with the hope that it makes it easier to discuss the 
general approach and any other concerns the community may have.

KIP: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-795%3A+Add+public+APIs+for
+AbstractCoordinator
PR: https://github.com/apache/kafka/pull/11515

Looking forward for some community feedback.

Regards,
Hector

From: dev@kafka.apache.org At: 11/11/21 17:15:17 UTC-5:00To:  
dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Tom,

Thanks for taking time reviewing the KIP. 

I think it's reasonable to ask if Kafka's Group Coordination protocol should be 
used for use cases other than the distributed event log. This was actually 
briefly addressed by Gwen Shapira during her presentation at the strangeloop 
conference in '18 (a link to the video is included in the KIP), in which she 
explain in greater details the protocol internals.

We should also keep in mind that this protocol is already being used for other 
use cases outside of core Kafka: Confluent Schema Registry uses it to determine 
leadership between members of a cluster, Kafka Connect uses it for task 
assignments, same with Kafka Stream for partition and task distributions, and 
so on. So having a public, stable API not just for new use cases (like ours) 
but existing ones is IMHO a good thing to have. I'll amend the KIP and add a 
bit more details to the motivation and alternatives sections, so the usefulness 
of this KIP is better understood.

Now, for the first point of your technical observations (regarding 
protocolTypes()), I don't think it matters in this context, as the protocol 
name and subtype are only relevant in the context of a consumer group and group 
rebalance. It really doesn't matter if two different libraries decide to name 
their protocols the same.

For item #2, I was under the impression that, because these classes all 
implement the org.apache.kafka.common.protocol.[Message, ApiMessage] interface, 
they are implicitly part of the Kafka protocol and the top-level API. Isn't 
that really the case?

And finally, for #3, the goal I had in mind when creating this KPI was a small 
one: to provide an interface that users can rely on when extending the 
AbstactCoordinator. So my thought was that, while the AbstractCoordinator 
itself uses some internal APIs (like ConsumerNetworkClient, ConsumerMetadata 
and so on) those can remain internal. But it probably makes sense to at least 
explore the possibility of moving the whole AbstractCoordinator class to be 
part of the public API. I'll do that exercise, see what it entails, and update 
the KIP with my findings.


Thanks again!
Hector


From: dev@kafka.apache.org At: 11/10/21 06:43:59 UTC-5:00To:  Hector Geraldino 
(BLOOMBERG/ 919 3RD A ) ,  dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Hector,

Thanks for the KIP.

At a high level, I think the question to be answered by the community is
"Should Kafka really be providing this kind of cluster management API?".
While Kafka clients need this to provide their functionality it's a
different thing to expose that as a public API of the project, which is
otherwise about providing a distributed event log/data streaming
platform/. Having a public
API brings a significant commitment for API compatibility, which could
impair the ability of the project to change the API in order to make
improvements to the Kafka clients. The current AbstractCoordinator not
being a supported API means we don't currently have to reason about
compatibility here. So I think it would help the motivation section of the
KIP to describe in a bit more detail the use case(s) you have for
implementing your own co

Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of

2021-12-13 Thread Hector Martin


On 13/12/2021 20.30, Javier Martinez Canillas wrote:

On Mon, Dec 13, 2021 at 11:46 AM Hector Martin  wrote:


On 13/12/2021 17.44, Javier Martinez Canillas wrote:

Hello Hector,

On Sun, Dec 12, 2021 at 7:24 AM Hector Martin  wrote:


This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Acked-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
   drivers/of/platform.c  |  4 
   drivers/video/fbdev/simplefb.c | 21 +
   2 files changed, 5 insertions(+), 20 deletions(-)



This is indeed a much better approach than what I suggested. I just
have one comment.


diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..793350028906 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void)
  of_node_put(node);
  }

+   node = of_get_compatible_child(of_chosen, "simple-framebuffer");


You have to check if the node variable is NULL here.


+   of_platform_device_create(node, NULL, NULL);


Otherwise this could lead to a NULL pointer dereference if debug
output is enabled (the node->full_name is printed).


Where is it printed? I thought I might need a NULL check, but this code


Sorry, I misread of_amba_device_create() as
of_platform_device_create(), which uses the "%pOF" printk format
specifier [0] to print the node's full name as a debug output [1].

[0]: 
https://elixir.bootlin.com/linux/v5.16-rc5/source/Documentation/core-api/printk-formats.rst#L462
[1]: 
https://elixir.bootlin.com/linux/v5.16-rc5/source/drivers/of/platform.c#L233


was suggested verbatim by Rob in v2 without the NULL check and digging
through I found that the NULL codepath is safe.



You are right that passing NULL is a safe code path for now due the
of_device_is_available(node) check, but that seems fragile to me since
just adding a similar debug output to of_platform_device_create()
could trigger the NULL pointer dereference.


Since Rob is the DT maintainer, I'm going to defer to his opinion on 
this one :-)


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

Re: [PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of

2021-12-13 Thread Hector Martin


On 13/12/2021 17.44, Javier Martinez Canillas wrote:

Hello Hector,

On Sun, Dec 12, 2021 at 7:24 AM Hector Martin  wrote:


This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Acked-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
  drivers/of/platform.c  |  4 
  drivers/video/fbdev/simplefb.c | 21 +
  2 files changed, 5 insertions(+), 20 deletions(-)



This is indeed a much better approach than what I suggested. I just
have one comment.


diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..793350028906 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void)
 of_node_put(node);
 }

+   node = of_get_compatible_child(of_chosen, "simple-framebuffer");


You have to check if the node variable is NULL here.


+   of_platform_device_create(node, NULL, NULL);


Otherwise this could lead to a NULL pointer dereference if debug
output is enabled (the node->full_name is printed).


Where is it printed? I thought I might need a NULL check, but this code 
was suggested verbatim by Rob in v2 without the NULL check and digging 
through I found that the NULL codepath is safe.


of_platform_device_create calls of_platform_device_create_pdata 
directly, and:


static struct platform_device *of_platform_device_create_pdata(
struct device_node *np,
const char *bus_id,
void *platform_data,
struct device *parent)
{
struct platform_device *dev;

if (!of_device_is_available(np) ||
of_node_test_and_set_flag(np, OF_POPULATED))
return NULL;

of_device_is_available takes a global spinlock and then calls 
__of_device_is_available, and that does:


static bool __of_device_is_available(const struct device_node *device)
{
const char *status;
int statlen;

if (!device)
return false;

... so I don't see how this can do anything but immediately return false 
if node is NULL.


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH v3 3/3] drm/simpledrm: Add [AX]RGB2101010 formats

This is the format used by the bootloader framebuffer on Apple ARM64
platforms.

Reviewed-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2f15b9aa..b977f5c94562 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,8 +571,8 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
-   //DRM_FORMAT_ARGB2101010,
+   DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_ARGB2101010,
 };
 
 static const uint64_t simpledrm_format_modifiers[] = {
-- 
2.33.0

[PATCH v3 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 64 +
 include/drm/drm_format_helper.h |  3 ++
 2 files changed, 67 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..0f28dd2bdd72 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,61 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+   u32 val32;
+
+   for (x = 0; x < pixels; x++) {
+   val32 = ((sbuf[x] & 0x00FF) << 2) |
+   ((sbuf[x] & 0xFF00) << 4) |
+   ((sbuf[x] & 0x00FF) << 6);
+   *dbuf++ = val32 | ((val32 >> 8) & 0x00300C03);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
+unsigned int dst_pitch, const void 
*vaddr,
+const struct drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * sizeof(u32);
+   unsigned int y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   if (!dst_pitch)
+   dst_pitch = dst_len;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -500,6 +555,10 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
@@ -515,6 +574,11 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap, 
fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_toio(dst, dst_pitch, 
vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 97e4c3223af3..b30ed5de0a33 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -33,6 +33,9 @@ void drm_fb_xrgb_to_rgb888(void *dst, unsigned int 
dst_pitch, const void *sr
 void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int dst_pitch,
const void *vaddr, const struct 
drm_framebuffer *fb,
const struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int 
dst_pitch,
+const void *vaddr, const struct 
drm_framebuffer *fb,
+const struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void 
*vaddr,
  const struct drm_framebuffer *fb, const struct 
drm_rect *clip);
 
-- 
2.33.0

[PATCH v3 1/3] of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Acked-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/of/platform.c  |  4 
 drivers/video/fbdev/simplefb.c | 21 +
 2 files changed, 5 insertions(+), 20 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..793350028906 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,10 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
 
+   node = of_get_compatible_child(of_chosen, "simple-framebuffer");
+   of_platform_device_create(node, NULL, NULL);
+   of_node_put(node);
+
/* Populate everything else. */
of_platform_default_populate(NULL, NULL, NULL);
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index b63074fd892e..57541887188b 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -541,26 +541,7 @@ static struct platform_driver simplefb_driver = {
.remove = simplefb_remove,
 };
 
-static int __init simplefb_init(void)
-{
-   int ret;
-   struct device_node *np;
-
-   ret = platform_driver_register(_driver);
-   if (ret)
-   return ret;
-
-   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
-   for_each_child_of_node(of_chosen, np) {
-   if (of_device_is_compatible(np, "simple-framebuffer"))
-   of_platform_device_create(np, NULL, NULL);
-   }
-   }
-
-   return 0;
-}
-
-fs_initcall(simplefb_init);
+module_platform_driver(simplefb_driver);
 
 MODULE_AUTHOR("Stephen Warren ");
 MODULE_DESCRIPTION("Simple framebuffer driver");
-- 
2.33.0

[PATCH v3 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

Hi DRM folks,

This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.

This avoids breaking the bootloader-provided framebuffer console when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).

Changes since v2:
- Made 10-bit conversion code fill the LSBs
- Added ARGB2101010 to supported formats list
- Simplified OF core code per review feedback
Hector Martin (3):
  of: Move simple-framebuffer device handling from simplefb to of
  drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_toio()
  drm/simpledrm: Add [AX]RGB2101010 formats

 drivers/gpu/drm/drm_format_helper.c | 64 +
 drivers/gpu/drm/tiny/simpledrm.c|  4 +-
 drivers/of/platform.c   |  4 ++
 drivers/video/fbdev/simplefb.c  | 21 +-
 include/drm/drm_format_helper.h |  3 ++
 5 files changed, 74 insertions(+), 22 deletions(-)

-- 
2.33.0

[jira] [Updated] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)



 [ 
https://issues.apache.org/jira/browse/KAFKA-13521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hector Geraldino updated KAFKA-13521:
-
Issue Type: Bug  (was: Improvement)

> Supress changelog schema version breaks migration
> -
>
> Key: KAFKA-13521
> URL: https://issues.apache.org/jira/browse/KAFKA-13521
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 2.4.0, 2.5.0, 2.5.1
>Reporter: Hector Geraldino
>Priority: Major
>
> Hi,
> We recently updated the kafka-streams library in one of our apps from v2.5.0 
> to v2.5.1. This upgrade changes the header format of the state store for 
> suppress changelog topics (see 
> https://issues.apache.org/jira/browse/KAFKA-10173 and 
> [https://github.com/apache/kafka/pull/8905)]
> What we noticed was that, introducing a new version on the binary schema 
> header breaks older clients. I.e. applications running on v2.5.1 can parse 
> the v3, v2, v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, 
> previous versions) cannot read headers in v3 format.
> The logged exception is:
>  
> {code:java}
> java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
> record: ConsumerRecord(topic = 
> msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
> partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
> 1638828473341, serialized key size = 32, serialized value size = 90, headers 
> = RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
> false), key = [B@5cf0e540, value = [B@40abc004)
>   at 
> org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
>  ~[msgequator-1.59.3.jar:1.59.3]
>   at 
> org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
>  ~[msgequator-1.59.3.jar:1.59.3] {code}
>  
>  
> There's obviously no clear solution for this other than stopping/starting all 
> instances at once. A rolling bounce that takes some time to complete (in our 
> case, days) will break  instances that haven't been upgraded yet after a 
> rebalance that causes older clients to pick up the newly encoded changelog 
> partition(s)
>  
> I don't know if adding a flag on the client side that lists the supported 
> protocol versions (so it behaves like Kafka Consumers when picking the 
> rebalance protocol - cooperative or eager), or if it just needs to be 
> explicitly stated on the migration guide that a full stop/start migration is 
> required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)

Hector Geraldino created KAFKA-13521:


 Summary: Supress changelog schema version breaks migration
 Key: KAFKA-13521
 URL: https://issues.apache.org/jira/browse/KAFKA-13521
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Affects Versions: 2.5.1, 2.5.0, 2.4.0
Reporter: Hector Geraldino


Hi,

We recently updated the kafka-streams library in one of our apps from v2.5.0 to 
v2.5.1. This upgrade changes the header format of the state store for suppress 
changelog topics (see https://issues.apache.org/jira/browse/KAFKA-10173 and 
[https://github.com/apache/kafka/pull/8905)]

What we noticed was that, introducing a new version on the binary schema header 
breaks older clients. I.e. applications running on v2.5.1 can parse the v3, v2, 
v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, previous 
versions) cannot read headers in v3 format.

The logged exception is:

 
{code:java}
java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
record: ConsumerRecord(topic = 
msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
1638828473341, serialized key size = 32, serialized value size = 90, headers = 
RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
false), key = [B@5cf0e540, value = [B@40abc004)
at 
org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
 ~[msgequator-1.59.3.jar:1.59.3] {code}
 

 

There's obviously no clear solution for this other than stopping/starting all 
instances at once. A rolling bounce that takes some time to complete (in our 
case, days) will break  instances that haven't been upgraded yet after a 
rebalance that causes older clients to pick up the newly encoded changelog 
partition(s)

 

I don't know if adding a flag on the client side that lists the supported 
protocol versions (so it behaves like Kafka Consumers when picking the 
rebalance protocol - cooperative or eager), or if it just needs to be 
explicitly stated on the migration guide that a full stop/start migration is 
required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (KAFKA-13521) Supress changelog schema version breaks migration

2021-12-08 Thread Hector Geraldino (Jira)

Hector Geraldino created KAFKA-13521:


 Summary: Supress changelog schema version breaks migration
 Key: KAFKA-13521
 URL: https://issues.apache.org/jira/browse/KAFKA-13521
 Project: Kafka
  Issue Type: Improvement
  Components: streams
Affects Versions: 2.5.1, 2.5.0, 2.4.0
Reporter: Hector Geraldino


Hi,

We recently updated the kafka-streams library in one of our apps from v2.5.0 to 
v2.5.1. This upgrade changes the header format of the state store for suppress 
changelog topics (see https://issues.apache.org/jira/browse/KAFKA-10173 and 
[https://github.com/apache/kafka/pull/8905)]

What we noticed was that, introducing a new version on the binary schema header 
breaks older clients. I.e. applications running on v2.5.1 can parse the v3, v2, 
v1 and 0 headers, while the ones running on 2.5.0 (and, I assume, previous 
versions) cannot read headers in v3 format.

The logged exception is:

 
{code:java}
java.lang.IllegalArgumentException: Restoring apparently invalid changelog 
record: ConsumerRecord(topic = 
msgequator-kfns-msgequator-msgequator-suppress-buffer-store-changelog, 
partition = 8, leaderEpoch = 405, offset = 711400430, CreateTime = 
1638828473341, serialized key size = 32, serialized value size = 90, headers = 
RecordHeaders(headers = [RecordHeader(key = v, value = [3])], isReadOnly = 
false), key = [B@5cf0e540, value = [B@40abc004)
at 
org.apache.kafka.streams.state.internals.InMemoryTimeOrderedKeyValueBuffer.restoreBatch(InMemoryTimeOrderedKeyValueBuffer.java:372)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.CompositeRestoreListener.restoreBatch(CompositeRestoreListener.java:89)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StateRestorer.restore(StateRestorer.java:92)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.processNext(StoreChangelogReader.java:350)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StoreChangelogReader.restore(StoreChangelogReader.java:94)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.TaskManager.updateNewAndRestoringTasks(TaskManager.java:401)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runOnce(StreamThread.java:779)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.runLoop(StreamThread.java:697)
 ~[msgequator-1.59.3.jar:1.59.3]
at 
org.apache.kafka.streams.processor.internals.StreamThread.run(StreamThread.java:670)
 ~[msgequator-1.59.3.jar:1.59.3] {code}
 

 

There's obviously no clear solution for this other than stopping/starting all 
instances at once. A rolling bounce that takes some time to complete (in our 
case, days) will break  instances that haven't been upgraded yet after a 
rebalance that causes older clients to pick up the newly encoded changelog 
partition(s)

 

I don't know if adding a flag on the client side that lists the supported 
protocol versions (so it behaves like Kafka Consumers when picking the 
rebalance protocol - cooperative or eager), or if it just needs to be 
explicitly stated on the migration guide that a full stop/start migration is 
required in cases where the protocol version changes.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Re: [PATCH v2 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

2021-12-07 Thread Hector Martin


Hi, thanks for the review!

On 07/12/2021 18.40, Thomas Zimmermann wrote:

Hi

Am 07.12.21 um 08:29 schrieb Hector Martin:

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
   drivers/gpu/drm/drm_format_helper.c | 62 +
   include/drm/drm_format_helper.h |  3 ++
   2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..edd611d3ab6a 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,59 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
   }
   EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
   
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,

+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);


This isn't quite right. The lowest two destination bits in each
component will always be zero. You have to do the shifting as above and
for each component the two highest source bits have to be OR'ed into the
two lowest destination bits. For example the source bits in a component
are numbered 7 to 0

   | 7 6 5 4 3 2 1 0 |

then the destination bits should be

   | 7 6 5 4 3 2 1 0 7 6 |



I think both approaches have pros and cons. Leaving the two LSBs always 
at 0 yields a fully linear transfer curve with no discontinuities, but 
means the maximum brightness is slightly less than full. Setting them 
fully maps the brightness range, but creates 4 double wide steps in the 
transfer curve (also it's potentially slightly slower CPU-wise).


If you prefer the latter I'll do that for v2.

--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH v2 3/3] drm/simpledrm: Add XRGB2101010 format

This is the format used by the bootloader framebuffer on Apple ARM64
platforms.

Reviewed-by: Thomas Zimmermann 
Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2f15b9aa..edadfd9ee882 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,7 +571,7 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XRGB2101010,
//DRM_FORMAT_ARGB2101010,
 };
 
-- 
2.33.0

[PATCH v2 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_toio()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 62 +
 include/drm/drm_format_helper.h |  3 ++
 2 files changed, 65 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index dbe3e830096e..edd611d3ab6a 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -409,6 +409,59 @@ void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, 
unsigned int dst_pitch,
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_toio);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, const u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_toio - Convert XRGB to XRGB2101010 clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: Number of bytes between two consecutive scanlines within dst
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ */
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst,
+unsigned int dst_pitch, const void 
*vaddr,
+const struct drm_framebuffer *fb,
+const struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * sizeof(u32);
+   unsigned y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   if (!dst_pitch)
+   dst_pitch = dst_len;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_toio);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -500,6 +553,10 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_toio(dst, dst_pitch, vmap, fb, clip);
@@ -515,6 +572,11 @@ int drm_fb_blit_toio(void __iomem *dst, unsigned int 
dst_pitch, uint32_t dst_for
drm_fb_xrgb_to_rgb888_toio(dst, dst_pitch, vmap, 
fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_toio(dst, dst_pitch, 
vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index 97e4c3223af3..b30ed5de0a33 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -33,6 +33,9 @@ void drm_fb_xrgb_to_rgb888(void *dst, unsigned int 
dst_pitch, const void *sr
 void drm_fb_xrgb_to_rgb888_toio(void __iomem *dst, unsigned int dst_pitch,
const void *vaddr, const struct 
drm_framebuffer *fb,
const struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_toio(void __iomem *dst, unsigned int 
dst_pitch,
+const void *vaddr, const struct 
drm_framebuffer *fb,
+const struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(void *dst, unsigned int dst_pitch, const void 
*vaddr,
  const struct drm_framebuffer *fb, const struct 
drm_rect *clip);
 
-- 
2.33.0

[PATCH v2 1/3] of: Move simple-framebuffer device handling from simplefb to of

This code is required for both simplefb and simpledrm, so let's move it
into the OF core instead of having it as an ad-hoc initcall in the
drivers.

Signed-off-by: Hector Martin 
---
 drivers/of/platform.c  |  5 +
 drivers/video/fbdev/simplefb.c | 21 +
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b3faf89744aa..e097f40b03c0 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -540,6 +540,11 @@ static int __init of_platform_default_populate_init(void)
of_node_put(node);
}
 
+   for_each_child_of_node(of_chosen, node) {
+   if (of_device_is_compatible(node, "simple-framebuffer"))
+   of_platform_device_create(node, NULL, NULL);
+   }
+
/* Populate everything else. */
of_platform_default_populate(NULL, NULL, NULL);
 
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index b63074fd892e..57541887188b 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -541,26 +541,7 @@ static struct platform_driver simplefb_driver = {
.remove = simplefb_remove,
 };
 
-static int __init simplefb_init(void)
-{
-   int ret;
-   struct device_node *np;
-
-   ret = platform_driver_register(_driver);
-   if (ret)
-   return ret;
-
-   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
-   for_each_child_of_node(of_chosen, np) {
-   if (of_device_is_compatible(np, "simple-framebuffer"))
-   of_platform_device_create(np, NULL, NULL);
-   }
-   }
-
-   return 0;
-}
-
-fs_initcall(simplefb_init);
+module_platform_driver(simplefb_driver);
 
 MODULE_AUTHOR("Stephen Warren ");
 MODULE_DESCRIPTION("Simple framebuffer driver");
-- 
2.33.0

[PATCH v2 0/3] drm/simpledrm: Apple M1 / DT platform support fixes

Hi DRM folks,

This short series makes simpledrm work on Apple M1 (including Pro/Max)
platforms the way simplefb already does, by adding XRGB2101010 support
and making it bind to framebuffers in /chosen the same way simplefb
does.

This avoids breaking the bootloader-provided framebuffer console when
simpledrm is selected to replace simplefb, as these FBs always seem to
be 10-bit (at least when a real screen is attached).

Changes since v1:
- Moved the OF platform device setup code from simplefb into common
  code, instead of duplicating it in simpledrm
- Rebased on drm-tip

Hector Martin (3):
  of: Move simple-framebuffer device handling from simplefb to of
  drm/format-helper: Add drm_fb_xrgb_to_xrgb2101010_toio()
  drm/simpledrm: Add XRGB2101010 format

 drivers/gpu/drm/drm_format_helper.c | 62 +
 drivers/gpu/drm/tiny/simpledrm.c|  2 +-
 drivers/of/platform.c   |  5 +++
 drivers/video/fbdev/simplefb.c  | 21 +-
 include/drm/drm_format_helper.h |  3 ++
 5 files changed, 72 insertions(+), 21 deletions(-)

-- 
2.33.0

Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

2021-11-29 Thread Hector Geraldino (BLOOMBERG/ 919 3RD A)

Hello again Tom, kafka devs

First, congrats on becoming a PMC member! That's so cool.

Since your last reply I've updated the KIP trying to address some of your 
suggestions. A few more details have been added to the motivation section, and 
also went ahead and opened a draft pull-request with the changes I think are 
needed for this KIP, with the hope that it makes it easier to discuss the 
general approach and any other concerns the community may have.

KIP: 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-795%3A+Add+public+APIs+for+AbstractCoordinator
PR: https://github.com/apache/kafka/pull/11515

Looking forward for some community feedback.

Regards,
Hector

From: dev@kafka.apache.org At: 11/11/21 17:15:17 UTC-5:00To:  
dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Tom,

Thanks for taking time reviewing the KIP. 

I think it's reasonable to ask if Kafka's Group Coordination protocol should be 
used for use cases other than the distributed event log. This was actually 
briefly addressed by Gwen Shapira during her presentation at the strangeloop 
conference in '18 (a link to the video is included in the KIP), in which she 
explain in greater details the protocol internals.

We should also keep in mind that this protocol is already being used for other 
use cases outside of core Kafka: Confluent Schema Registry uses it to determine 
leadership between members of a cluster, Kafka Connect uses it for task 
assignments, same with Kafka Stream for partition and task distributions, and 
so on. So having a public, stable API not just for new use cases (like ours) 
but existing ones is IMHO a good thing to have. I'll amend the KIP and add a 
bit more details to the motivation and alternatives sections, so the usefulness 
of this KIP is better understood.

Now, for the first point of your technical observations (regarding 
protocolTypes()), I don't think it matters in this context, as the protocol 
name and subtype are only relevant in the context of a consumer group and group 
rebalance. It really doesn't matter if two different libraries decide to name 
their protocols the same.

For item #2, I was under the impression that, because these classes all 
implement the org.apache.kafka.common.protocol.[Message, ApiMessage] interface, 
they are implicitly part of the Kafka protocol and the top-level API. Isn't 
that really the case?

And finally, for #3, the goal I had in mind when creating this KPI was a small 
one: to provide an interface that users can rely on when extending the 
AbstactCoordinator. So my thought was that, while the AbstractCoordinator 
itself uses some internal APIs (like ConsumerNetworkClient, ConsumerMetadata 
and so on) those can remain internal. But it probably makes sense to at least 
explore the possibility of moving the whole AbstractCoordinator class to be 
part of the public API. I'll do that exercise, see what it entails, and update 
the KIP with my findings.


Thanks again!
Hector


From: dev@kafka.apache.org At: 11/10/21 06:43:59 UTC-5:00To:  Hector Geraldino 
(BLOOMBERG/ 919 3RD A ) ,  dev@kafka.apache.org
Subject: Re: [DISCUSS] KIP-795: Add public APIs for AbstractCoordinator

Hi Hector,

Thanks for the KIP.

At a high level, I think the question to be answered by the community is
"Should Kafka really be providing this kind of cluster management API?".
While Kafka clients need this to provide their functionality it's a
different thing to expose that as a public API of the project, which is
otherwise about providing a distributed event log/data streaming
platform/. Having a public
API brings a significant commitment for API compatibility, which could
impair the ability of the project to change the API in order to make
improvements to the Kafka clients. The current AbstractCoordinator not
being a supported API means we don't currently have to reason about
compatibility here. So I think it would help the motivation section of the
KIP to describe in a bit more detail the use case(s) you have for
implementing your own coordinators. For example, are these applications
using Kafka otherwise, or just to leverage this API? And what alternatives
to implementing your own coordinators did you consider, and why did you
reject them?

From a technical point of view, there are a number of issues I think would
need addressing in order to do something like this:

1. There probably ought to be a way to ensure that protocolTypes() don't
collide, or at least reduce the chances of a collision. While probably
unlikely in practice the consequences of different protocols having the
same name could be pretty confusing to debug.
2. JoinGroupRequestData and JoinGroupResponseData are not public classes
(none of the *RequestData or *ResponseData classes are, intentionally), so
there would have to be an abstraction for them.
3. It's all well and good having an interface that anyone can implement,
but there is no supported Kafka API w

Re: [PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

2021-11-22 Thread Hector Martin


On 22/11/2021 18.52, Pekka Paalanen wrote:

On Wed, 17 Nov 2021 23:58:28 +0900
Hector Martin  wrote:


Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.

Signed-off-by: Hector Martin 
---
  drivers/gpu/drm/drm_format_helper.c | 64 +
  include/drm/drm_format_helper.h |  4 ++
  2 files changed, 68 insertions(+)


Hi Hector,

I'm curious, since the bootloader seems to always set up a 10-bit mode,
is there a reason for it that you can guess? Is the monitor in WCG or
even HDR mode?


My guess is that Apple prefer to use 10-bit framebuffers for seamless 
handover with their graphics stack, which presumably uses 10-bit 
framebuffers these days. It seems to be unconditional; I've never seen 
anything but 10 bits across all Apple devices, both with the internal 
panels on laptops and with bog standard external displays on the Mac 
Mini via HDMI. HDR is not necessary, even very dumb capture cards and 
old screens get a 10-bit framebufer in memory.


The only time I see an 8-bit framebuffer is with *no* monitor connected 
on the Mini, in which case you get an 8-bit 640x1136 dummy framebuffer 
(that's the iPhone 5 screen resolution... :-) )


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

Re: reportbug fail

2021-11-21 Thread Richard Hector


On 21/11/21 3:04 am, Lee wrote:

I wanted to create a bug report for meld but couldn't find any info on
how to other than "use reportbug" :(


I see your problem is solved, but for future reference, this page has 
info on reporting bugs via email:


https://www.debian.org/Bugs/Reporting

Cheers,
Richard

Re: [PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen

2021-11-19 Thread Hector Martin


On 18/11/2021 18.19, Thomas Zimmermann wrote:

Hi

Am 17.11.21 um 15:58 schrieb Hector Martin:

@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
   
   module_platform_driver(simpledrm_platform_driver);
   
+static int __init simpledrm_init(void)

+{
+   struct device_node *np;
+
+   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
+   for_each_child_of_node(of_chosen, np) {
+   if (of_device_is_compatible(np, "simple-framebuffer"))
+   of_platform_device_create(np, NULL, NULL);
+   }
+   }
+
+   return 0;
+}
+
+fs_initcall(simpledrm_init);
+


Simpledrm is just a driver, but this is platform setup code. Why is this
code located here and not under arch/ or drivers/firmware/?

I know that other drivers do similar things, it doesn't seem to belong here.


This definitely doesn't belong in either of those, since it is not arch- 
or firmware-specific. It is implementing support for the standard 
simple-framebuffer OF binding, which specifies that it must be located 
within the /chosen node (and thus the default OF setup code won't do the 
matching for you); this applies to all OF platforms [1]


Adding Rob; do you think this should move from simplefb/simpledrm to 
common OF code? (where?)


[1] Documentation/devicetree/bindings/display/simple-framebuffer.yaml

--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH v2] iommu/io-pgtable-arm: Fix table descriptor paddr formatting

2021-11-19 Thread Hector Martin

Table descriptors were being installed without properly formatting the
address using paddr_to_iopte, which does not match up with the
iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
format, as it does not handle the high bits properly.

This was found on Apple T6000 DARTs, which require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.

Fixes: 6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address")
Acked-by: Robin Murphy 
Signed-off-by: Hector Martin 
---
 drivers/iommu/io-pgtable-arm.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dd9e47189d0d..94ff319ae8ac 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -315,11 +315,12 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
 static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
 arm_lpae_iopte *ptep,
 arm_lpae_iopte curr,
-struct io_pgtable_cfg *cfg)
+struct arm_lpae_io_pgtable *data)
 {
arm_lpae_iopte old, new;
+   struct io_pgtable_cfg *cfg = >iop.cfg;
 
-   new = __pa(table) | ARM_LPAE_PTE_TYPE_TABLE;
+   new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
new |= ARM_LPAE_PTE_NSTABLE;
 
@@ -380,7 +381,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, 
unsigned long iova,
if (!cptep)
return -ENOMEM;
 
-   pte = arm_lpae_install_table(cptep, ptep, 0, cfg);
+   pte = arm_lpae_install_table(cptep, ptep, 0, data);
if (pte)
__arm_lpae_free_pages(cptep, tblsz, cfg);
} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
@@ -592,7 +593,7 @@ static size_t arm_lpae_split_blk_unmap(struct 
arm_lpae_io_pgtable *data,
__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, [i]);
}
 
-   pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
+   pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
if (pte != blk_pte) {
__arm_lpae_free_pages(tablep, tablesz, cfg);
/*
-- 
2.33.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Bug#1000139: lxc-templates: Bad security sources on bullseye container built on buster

2021-11-18 Thread Richard Hector

Package: lxc-templates
Version: 3.0.4-0+deb10u1
Severity: normal

Dear Maintainer,

Bug #970067 has been fixed, enabling the building of bullseye machines
with a correct sources.list

It is only available in bullseye+, however, so building a bullseye
container on buster doesn't work correctly (the security sources line is
wrong).

Could this be fixed in buster as well?

Thanks,
Richard

[ansible-project] lineinfile in lxc_container?

2021-11-18 Thread Richard Hector

Hi all,

I'm using ansible to set up lxc containers, using delegation to the
container host.

One task looks like this:

- name: add ansible user to sudoers
lineinfile:
dest: "/var/lib/lxc/{{ inventory_hostname }}/rootfs/etc/sudoers"
state: present
regexp: "^ansible"
line: 'ansible ALL=(ALL) NOPASSWD: ALL'
insertafter: '^root'
validate: '/usr/sbin/visudo -cf %s'
delegate_to: "{{ container_host }}"
when: start_container|bool

That has been working fine, until I tried to create a debian bullseye
container on a buster host. Unfortunately, the sudoers format has
changed slightly, so the buster visudo won't accept the bullseye sudoers
file (#includedir is now @includedir).

I tried giving the path to the bullseye visudo, but it's dynamically
linked and doesn't work on the buster system.

I could potentially use the lxc_container module to run a command in the
container, but that means I lose lineinfile, and have to do more stuff
manually.

Or I could use my temporary workaround, and just assume my sudoers file
is ok, and skip validation.

Another option is to add an extra lineinfile task (before that one) to
replace @includedir with #includedir, since it's backwards compatible,
but that seems too hackish.

Any other suggestions?

Cheers,
Richard

--
You received this message because you are subscribed to the Google Groups "Ansible
Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ansible-project+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/39771264-b079-ff6e-15a6-e018d95dd6fd%40walnut.gen.nz.

[PATCH] iommu/io-pgtable-arm: Fix table descriptor paddr formatting

Table descriptors were being installed without properly formatting the
address using paddr_to_iopte, which does not match up with the
iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte
format, as it does not handle the high bits properly.

This was found on Apple T6000 DARTs, which require a new pte format
(different shift); adding support for that to
paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit
addresses would end up incorrect in that case.

Signed-off-by: Hector Martin 
---
 drivers/iommu/io-pgtable-arm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index dd9e47189d0d..b636e2737607 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -315,12 +315,12 @@ static int arm_lpae_init_pte(struct arm_lpae_io_pgtable 
*data,
 static arm_lpae_iopte arm_lpae_install_table(arm_lpae_iopte *table,
 arm_lpae_iopte *ptep,
 arm_lpae_iopte curr,
-struct io_pgtable_cfg *cfg)
+struct arm_lpae_io_pgtable *data)
 {
arm_lpae_iopte old, new;
 
-   new = __pa(table) | ARM_LPAE_PTE_TYPE_TABLE;
-   if (cfg->quirks & IO_PGTABLE_QUIRK_ARM_NS)
+   new = paddr_to_iopte(__pa(table), data) | ARM_LPAE_PTE_TYPE_TABLE;
+   if (data->iop.cfg.quirks & IO_PGTABLE_QUIRK_ARM_NS)
new |= ARM_LPAE_PTE_NSTABLE;
 
/*
@@ -332,11 +332,11 @@ static arm_lpae_iopte 
arm_lpae_install_table(arm_lpae_iopte *table,
 
old = cmpxchg64_relaxed(ptep, curr, new);
 
-   if (cfg->coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
+   if (data->iop.cfg.coherent_walk || (old & ARM_LPAE_PTE_SW_SYNC))
return old;
 
/* Even if it's not ours, there's no point waiting; just kick it */
-   __arm_lpae_sync_pte(ptep, 1, cfg);
+   __arm_lpae_sync_pte(ptep, 1, >iop.cfg);
if (old == curr)
WRITE_ONCE(*ptep, new | ARM_LPAE_PTE_SW_SYNC);
 
@@ -380,7 +380,7 @@ static int __arm_lpae_map(struct arm_lpae_io_pgtable *data, 
unsigned long iova,
if (!cptep)
return -ENOMEM;
 
-   pte = arm_lpae_install_table(cptep, ptep, 0, cfg);
+   pte = arm_lpae_install_table(cptep, ptep, 0, data);
if (pte)
__arm_lpae_free_pages(cptep, tblsz, cfg);
} else if (!cfg->coherent_walk && !(pte & ARM_LPAE_PTE_SW_SYNC)) {
@@ -592,7 +592,7 @@ static size_t arm_lpae_split_blk_unmap(struct 
arm_lpae_io_pgtable *data,
__arm_lpae_init_pte(data, blk_paddr, pte, lvl, 1, [i]);
}
 
-   pte = arm_lpae_install_table(tablep, ptep, blk_pte, cfg);
+   pte = arm_lpae_install_table(tablep, ptep, blk_pte, data);
if (pte != blk_pte) {
__arm_lpae_free_pages(tablep, tablesz, cfg);
/*
-- 
2.33.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] drm/format-helper: Fix dst computation in drm_fb_xrgb8888_to_rgb888_dstclip()


On 17/11/2021 23.56, Thomas Zimmermann wrote:

Hi

Am 17.11.21 um 15:22 schrieb Hector Martin:

The dst pointer was being advanced by the clip width, not the full line
stride, resulting in corruption. The clip offset was also calculated
incorrectly.

Cc: sta...@vger.kernel.org
Signed-off-by: Hector Martin 


Thanks for your patch, but you're probably on the wrong branch. We
rewrote this code recently and fixed the issue in drm-misc-next. [1][2]


Oops. I was on linux-next as of Nov 1. Looks like I missed it by a week!

Sounds like I'm going to have to rebase/rewrite the other series I just 
sent too...


--
Hector Martin (mar...@marcan.st)
Public Key: https://mrcn.st/pub

[PATCH 3/3] drm/simpledrm: Enable XRGB2101010 format

This is the format used by the bootloader framebuffer on Apple ARM64
platforms, and is already supported by simplefb. This avoids regressing
on these platforms when simpledrm is enabled and replaces simplefb.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 2c84f2ea1fa2..b4b69f3a7e79 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -571,7 +571,7 @@ static const uint32_t simpledrm_default_formats[] = {
//DRM_FORMAT_XRGB1555,
//DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB888,
-   //DRM_FORMAT_XRGB2101010,
+   DRM_FORMAT_XRGB2101010,
//DRM_FORMAT_ARGB2101010,
 };
 
-- 
2.33.0

[PATCH 2/3] drm/format-helper: Add drm_fb_xrgb8888_to_xrgb2101010_dstclip()

Add XRGB emulation support for devices that can only do XRGB2101010.

This is chiefly useful for simpledrm on Apple devices where the
bootloader-provided framebuffer is 10-bit, which already works fine with
simplefb. This is required to make simpledrm support this too.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/drm_format_helper.c | 64 +
 include/drm/drm_format_helper.h |  4 ++
 2 files changed, 68 insertions(+)

diff --git a/drivers/gpu/drm/drm_format_helper.c 
b/drivers/gpu/drm/drm_format_helper.c
index 69fde60e36b3..5998e57d6ff2 100644
--- a/drivers/gpu/drm/drm_format_helper.c
+++ b/drivers/gpu/drm/drm_format_helper.c
@@ -378,6 +378,60 @@ void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, 
unsigned int dst_pitch
 }
 EXPORT_SYMBOL(drm_fb_xrgb_to_rgb888_dstclip);
 
+static void drm_fb_xrgb_to_xrgb2101010_line(u32 *dbuf, u32 *sbuf,
+   unsigned int pixels)
+{
+   unsigned int x;
+
+   for (x = 0; x < pixels; x++) {
+   *dbuf++ = ((sbuf[x] & 0x00FF) << 2) |
+ ((sbuf[x] & 0xFF00) << 4) |
+ ((sbuf[x] & 0x00FF) << 6);
+   }
+}
+
+/**
+ * drm_fb_xrgb_to_xrgb2101010_dstclip - Convert XRGB to XRGB2101010 
clip
+ * buffer
+ * @dst: XRGB2101010 destination buffer (iomem)
+ * @dst_pitch: destination buffer pitch
+ * @vaddr: XRGB source buffer
+ * @fb: DRM framebuffer
+ * @clip: Clip rectangle area to copy
+ *
+ * Drivers can use this function for XRGB2101010 devices that don't natively
+ * support XRGB.
+ *
+ * This function applies clipping on dst, i.e. the destination is a
+ * full (iomem) framebuffer but only the clip rect content is copied over.
+ */
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+   unsigned int dst_pitch, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_rect *clip)
+{
+   size_t linepixels = clip->x2 - clip->x1;
+   size_t dst_len = linepixels * 4;
+   unsigned int y, lines = clip->y2 - clip->y1;
+   void *dbuf;
+
+   dbuf = kmalloc(dst_len, GFP_KERNEL);
+   if (!dbuf)
+   return;
+
+   vaddr += clip_offset(clip, fb->pitches[0], sizeof(u32));
+   dst += clip_offset(clip, dst_pitch, sizeof(u32));
+   for (y = 0; y < lines; y++) {
+   drm_fb_xrgb_to_xrgb2101010_line(dbuf, vaddr, linepixels);
+   memcpy_toio(dst, dbuf, dst_len);
+   vaddr += fb->pitches[0];
+   dst += dst_pitch;
+   }
+
+   kfree(dbuf);
+}
+EXPORT_SYMBOL(drm_fb_xrgb_to_xrgb2101010_dstclip);
+
 /**
  * drm_fb_xrgb_to_gray8 - Convert XRGB to grayscale
  * @dst: 8-bit grayscale destination buffer
@@ -464,6 +518,10 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned 
int dst_pitch,
fb_format = DRM_FORMAT_XRGB;
if (dst_format == DRM_FORMAT_ARGB)
dst_format = DRM_FORMAT_XRGB;
+   if (fb_format == DRM_FORMAT_ARGB2101010)
+   fb_format = DRM_FORMAT_XRGB2101010;
+   if (dst_format == DRM_FORMAT_ARGB2101010)
+   dst_format = DRM_FORMAT_XRGB2101010;
 
if (dst_format == fb_format) {
drm_fb_memcpy_dstclip(dst, dst_pitch, vmap, fb, clip);
@@ -482,6 +540,12 @@ int drm_fb_blit_rect_dstclip(void __iomem *dst, unsigned 
int dst_pitch,
  vmap, fb, clip);
return 0;
}
+   } else if (dst_format == DRM_FORMAT_XRGB2101010) {
+   if (fb_format == DRM_FORMAT_XRGB) {
+   drm_fb_xrgb_to_xrgb2101010_dstclip(dst, dst_pitch,
+  vmap, fb, clip);
+   return 0;
+   }
}
 
return -EINVAL;
diff --git a/include/drm/drm_format_helper.h b/include/drm/drm_format_helper.h
index e86925cf07b9..a0faa710878b 100644
--- a/include/drm/drm_format_helper.h
+++ b/include/drm/drm_format_helper.h
@@ -29,6 +29,10 @@ void drm_fb_xrgb_to_rgb888(void *dst, void *src, struct 
drm_framebuffer *fb,
 void drm_fb_xrgb_to_rgb888_dstclip(void __iomem *dst, unsigned int 
dst_pitch,
   void *vaddr, struct drm_framebuffer *fb,
   struct drm_rect *clip);
+void drm_fb_xrgb_to_xrgb2101010_dstclip(void __iomem *dst,
+   unsigned int dst_pitch, void *vaddr,
+   struct drm_framebuffer *fb,
+   struct drm_rect *clip);
 void drm_fb_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer *fb,
  struct drm_rect *clip);
 
-- 
2.33.0

[PATCH 1/3] drm/simpledrm: Bind to OF framebuffers in /chosen

This matches the simplefb behavior; these nodes are not matched by the
standard OF machinery. This fixes a regression when simpledrm replaces
simeplefb.

Signed-off-by: Hector Martin 
---
 drivers/gpu/drm/tiny/simpledrm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/gpu/drm/tiny/simpledrm.c b/drivers/gpu/drm/tiny/simpledrm.c
index 481b48bde047..2c84f2ea1fa2 100644
--- a/drivers/gpu/drm/tiny/simpledrm.c
+++ b/drivers/gpu/drm/tiny/simpledrm.c
@@ -2,6 +2,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -897,5 +898,21 @@ static struct platform_driver simpledrm_platform_driver = {
 
 module_platform_driver(simpledrm_platform_driver);
 
+static int __init simpledrm_init(void)
+{
+   struct device_node *np;
+
+   if (IS_ENABLED(CONFIG_OF_ADDRESS) && of_chosen) {
+   for_each_child_of_node(of_chosen, np) {
+   if (of_device_is_compatible(np, "simple-framebuffer"))
+   of_platform_device_create(np, NULL, NULL);
+   }
+   }
+
+   return 0;
+}
+
+fs_initcall(simpledrm_init);
+
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL v2");
-- 
2.33.0

[PATCH 0/3] drm/simpledrm: Apple M1 / DT platform support fixes