[GSoC] Progress, Plans, and Questions
101 views
Skip to first unread message
WillyPillow
May 25, 2020, 1:19:12 PM5/25/20
to qubes...@googlegroups.com
Hi!
Firstly, thanks for accepting my proposal! (I meant to do a heads-up sooner,
but honestly I was distracted by some school stuff. My apologies.)
Some things I have done/am doing currently:
- Set up Qubes on my laptop.
- Went through some issues with tags "help wanted" and "P: minor" and made some
comments.
- Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
(Not directly related to Qubes, but this is relevant to my use case and AFAIK
the proprietary drivers do not really work on Qubes.)
- Submitted a PR to qubes-doc.
- Playing with qubes-builder.
- Skimming docs of PyGObject/GTK.
In the following days (possibly extending into the coding phase), I am planning
to experiment with the Admin API and hopefully make a script for creating
(e.g.) a Trojan [^1] firewall VM. [^2]
Also, regarding the timeline outlined in the proposal [^3], I should be able to
draft up an initial interface & design ASAP after the coding period starts and
post it here for further discussion. (Other suggestions for my goals for the
first few weeks are also appreciated!)
As a side note, since I am currently running R4.0 and may need to switch to
R4.1 for development later, I was wondering if it is possible to upgrade
in-place by, say, installing the built packages in dom0.
Thanks,
William Huang
[^1]: <https://github.com/trojan-gfw/trojan>
[^2]: <https://hackmd.io/@VVl_aGJQRpOYqPE9btxxBA/Hy31fYxvL>
[^3]: Perhaps this, by itself, is better suited for a Salt config? That being
said, my understanding is that the Admin API may be used to a larger extent in
this project, so I opted to go for that instead.
> https://blog.nerde.pw/
>
> PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
>
> Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E
Firstly, thanks for accepting my proposal! (I meant to do a heads-up sooner,
but honestly I was distracted by some school stuff. My apologies.)
Some things I have done/am doing currently:
- Set up Qubes on my laptop.
- Went through some issues with tags "help wanted" and "P: minor" and made some
comments.
- Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
(Not directly related to Qubes, but this is relevant to my use case and AFAIK
the proprietary drivers do not really work on Qubes.)
- Submitted a PR to qubes-doc.
- Playing with qubes-builder.
- Skimming docs of PyGObject/GTK.
In the following days (possibly extending into the coding phase), I am planning
to experiment with the Admin API and hopefully make a script for creating
(e.g.) a Trojan [^1] firewall VM. [^2]
Also, regarding the timeline outlined in the proposal [^3], I should be able to
draft up an initial interface & design ASAP after the coding period starts and
post it here for further discussion. (Other suggestions for my goals for the
first few weeks are also appreciated!)
As a side note, since I am currently running R4.0 and may need to switch to
R4.1 for development later, I was wondering if it is possible to upgrade
in-place by, say, installing the built packages in dom0.
Thanks,
William Huang
[^1]: <https://github.com/trojan-gfw/trojan>
[^2]: <https://hackmd.io/@VVl_aGJQRpOYqPE9btxxBA/Hy31fYxvL>
[^3]: Perhaps this, by itself, is better suited for a Salt config? That being
said, my understanding is that the Admin API may be used to a larger extent in
this project, so I opted to go for that instead.
> https://blog.nerde.pw/
>
> PGP fingerprint = 6CCF 3FC7 32AC 9D83 D154 217F 1C16 C70E E7C3 1C84
>
> Protonmail PGP = D02D CEFF ACE5 5A7B FF5D 871E 4004 1CB1 F52B 127E
Marek Marczykowski-Górecki
May 25, 2020, 11:52:55 PM5/25/20
to WillyPillow, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> Hi!
Hi!
> Firstly, thanks for accepting my proposal! (I meant to do a heads-up sooner,
> but honestly I was distracted by some school stuff. My apologies.)
>
> Some things I have done/am doing currently:
>
> - Set up Qubes on my laptop.
> - Went through some issues with tags "help wanted" and "P: minor" and made some
> comments.
> - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> the proprietary drivers do not really work on Qubes.)
I'd recommend trying newer kernel, if you haven't already:
https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
> - Submitted a PR to qubes-doc.
> - Playing with qubes-builder.
> - Skimming docs of PyGObject/GTK.
>
> In the following days (possibly extending into the coding phase), I am planning
> to experiment with the Admin API and hopefully make a script for creating
> (e.g.) a Trojan [^1] firewall VM. [^2]
>
> Also, regarding the timeline outlined in the proposal [^3], I should be able to
> draft up an initial interface & design ASAP after the coding period starts and
> post it here for further discussion. (Other suggestions for my goals for the
> first few weeks are also appreciated!)
Yes, this sounds like a good plan.
I would recommend leaving GUI for later time in the project as it may be
time-consuming and prevent you from finishing the actual mechanism in
time (working CLI would already be useful, but GUI that doesn't do
anything - not really).
> As a side note, since I am currently running R4.0 and may need to switch to
> R4.1 for development later, I was wondering if it is possible to upgrade
> in-place by, say, installing the built packages in dom0.
Generally yes, but the process involve several steps...
We have script for that in testing:
https://github.com/fepitre/qubes-migration
But since quite bit change (dom0 update fc31->fc32) just landed in
repos, I'd wait a week or two for things to stabilize. And in any case,
do a backup before such upgrade.
> Thanks,
>
> William Huang
>
> [^1]: <https://github.com/trojan-gfw/trojan>
>
> [^2]: <https://hackmd.io/@VVl_aGJQRpOYqPE9btxxBA/Hy31fYxvL>
>
> [^3]: Perhaps this, by itself, is better suited for a Salt config? That being
> said, my understanding is that the Admin API may be used to a larger extent in
> this project, so I opted to go for that instead.
Yes, configuring things within a VM is rather a task for salt. But you
can totally create VMs and set their properties via Admin API. In fact,
all qvm-* tools use Admin API to do their things. It's just not that
visible when running in dom0, because policy is bypassed in this case.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7MkpEACgkQ24/THMrX
1yzLwQf/bCPaOTojOBxMXzNPrDLjzC1zlj3kaN+UlTVmv9tgPo2b62a56VbAWPNC
rfLVYlEZjJoyHP/XerYbsx6OhRq1tIDPulohnySciQGhSnC1ZsleD1s30x0a0BWH
kZMCU4dVnkDox2Yr0nbl/44Lp0vdeOwscJgQx/mE0x3SHp8MU+AOPuuetnVJi8PZ
TIjTMDgSiuKTN7j+69TqkL+MFHJhr1wkbQKn3tgDdRU7jREZ24k6KAvVfaVMe0J1
wGeuaQJYNRQD1sAFZAJxvZ4YY5tsFHHWaThNEoOYhbAqCuDlh6ljP6upAhc65JiJ
uX6g1lxcNaM58qWcK+r5wkwjbjXzEw==
=R5hc
-----END PGP SIGNATURE-----
Hash: SHA256
On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> Hi!
Hi!
> Firstly, thanks for accepting my proposal! (I meant to do a heads-up sooner,
> but honestly I was distracted by some school stuff. My apologies.)
>
> Some things I have done/am doing currently:
>
> - Set up Qubes on my laptop.
> - Went through some issues with tags "help wanted" and "P: minor" and made some
> comments.
> - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> the proprietary drivers do not really work on Qubes.)
https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
> - Submitted a PR to qubes-doc.
> - Playing with qubes-builder.
> - Skimming docs of PyGObject/GTK.
>
> In the following days (possibly extending into the coding phase), I am planning
> to experiment with the Admin API and hopefully make a script for creating
> (e.g.) a Trojan [^1] firewall VM. [^2]
>
> Also, regarding the timeline outlined in the proposal [^3], I should be able to
> draft up an initial interface & design ASAP after the coding period starts and
> post it here for further discussion. (Other suggestions for my goals for the
> first few weeks are also appreciated!)
I would recommend leaving GUI for later time in the project as it may be
time-consuming and prevent you from finishing the actual mechanism in
time (working CLI would already be useful, but GUI that doesn't do
anything - not really).
> As a side note, since I am currently running R4.0 and may need to switch to
> R4.1 for development later, I was wondering if it is possible to upgrade
> in-place by, say, installing the built packages in dom0.
We have script for that in testing:
https://github.com/fepitre/qubes-migration
But since quite bit change (dom0 update fc31->fc32) just landed in
repos, I'd wait a week or two for things to stabilize. And in any case,
do a backup before such upgrade.
> Thanks,
>
> William Huang
>
> [^1]: <https://github.com/trojan-gfw/trojan>
>
> [^2]: <https://hackmd.io/@VVl_aGJQRpOYqPE9btxxBA/Hy31fYxvL>
>
> [^3]: Perhaps this, by itself, is better suited for a Salt config? That being
> said, my understanding is that the Admin API may be used to a larger extent in
> this project, so I opted to go for that instead.
can totally create VMs and set their properties via Admin API. In fact,
all qvm-* tools use Admin API to do their things. It's just not that
visible when running in dom0, because policy is bypassed in this case.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl7MkpEACgkQ24/THMrX
1yzLwQf/bCPaOTojOBxMXzNPrDLjzC1zlj3kaN+UlTVmv9tgPo2b62a56VbAWPNC
rfLVYlEZjJoyHP/XerYbsx6OhRq1tIDPulohnySciQGhSnC1ZsleD1s30x0a0BWH
kZMCU4dVnkDox2Yr0nbl/44Lp0vdeOwscJgQx/mE0x3SHp8MU+AOPuuetnVJi8PZ
TIjTMDgSiuKTN7j+69TqkL+MFHJhr1wkbQKn3tgDdRU7jREZ24k6KAvVfaVMe0J1
wGeuaQJYNRQD1sAFZAJxvZ4YY5tsFHHWaThNEoOYhbAqCuDlh6ljP6upAhc65JiJ
uX6g1lxcNaM58qWcK+r5wkwjbjXzEw==
=R5hc
-----END PGP SIGNATURE-----
WillyPillow
May 27, 2020, 11:18:17 PM5/27/20
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On Tuesday, May 26, 2020 11:52 AM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
> On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> >
> > - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> > (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> > the proprietary drivers do not really work on Qubes.)
> >
>
> I'd recommend trying newer kernel, if you haven't already:
> https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
>
I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
> On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> >
> > - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> > (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> > the proprietary drivers do not really work on Qubes.)
> >
>
> I'd recommend trying newer kernel, if you haven't already:
> https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
>
The issue I am running into is <https://bugs.freedesktop.org/show_bug.cgi?id=99501>.
I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
I tried poking around the nouveau DDX source code, with no success.
Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
My current workaround is to either use the display without rotation or use exclusively the dGPU and connect another display to replace the laptop one. (Since using the iGPU as a xrandr sink *also* results in distortion.)
It's not a *huge* issue for me, and I'm probably going to give in and spend my time elsewhere if I can't figure this out in the next few days. Would be great if a solution is found though.
> > - Submitted a PR to qubes-doc.
> > - Playing with qubes-builder.
> > - Skimming docs of PyGObject/GTK.
> >
> > In the following days (possibly extending into the coding phase), I am planning
> > to experiment with the Admin API and hopefully make a script for creating
> > (e.g.) a Trojan ^1 firewall VM. ^2
> > Also, regarding the timeline outlined in the proposal [^3], I should be able to
> > draft up an initial interface & design ASAP after the coding period starts and
> > post it here for further discussion. (Other suggestions for my goals for the
> > first few weeks are also appreciated!)
>
> Yes, this sounds like a good plan.
> I would recommend leaving GUI for later time in the project as it may be
> time-consuming and prevent you from finishing the actual mechanism in
> time (working CLI would already be useful, but GUI that doesn't do
> anything - not really).
> > As a side note, since I am currently running R4.0 and may need to switch to
> > R4.1 for development later, I was wondering if it is possible to upgrade
> > in-place by, say, installing the built packages in dom0.
>
> Generally yes, but the process involve several steps...
> We have script for that in testing:
> https://github.com/fepitre/qubes-migration
> But since quite bit change (dom0 update fc31->fc32) just landed in
> repos, I'd wait a week or two for things to stabilize. And in any case,
> do a backup before such upgrade.
> > Thanks,
> > William Huang
> > [^3]: Perhaps this, by itself, is better suited for a Salt config? That being
> > said, my understanding is that the Admin API may be used to a larger extent in
> > this project, so I opted to go for that instead.
>
> Yes, configuring things within a VM is rather a task for salt. But you
> can totally create VMs and set their properties via Admin API. In fact,
> all qvm-* tools use Admin API to do their things. It's just not that
> visible when running in dom0, because policy is bypassed in this case.
--WillyPillow
> > said, my understanding is that the Admin API may be used to a larger extent in
> > this project, so I opted to go for that instead.
>
> Yes, configuring things within a VM is rather a task for salt. But you
> can totally create VMs and set their properties via Admin API. In fact,
> all qvm-* tools use Admin API to do their things. It's just not that
> visible when running in dom0, because policy is bypassed in this case.
Marek Marczykowski-Górecki
May 27, 2020, 11:27:53 PM5/27/20
to WillyPillow, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
[moving to a separate sub-thread]
Hash: SHA256
On Thu, May 28, 2020 at 03:18:08AM +0000, WillyPillow wrote:
> On Tuesday, May 26, 2020 11:52 AM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
>
> > On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> > >
>
> > > - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> > > (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> > > the proprietary drivers do not really work on Qubes.)
> > >
>
> >
>
> > I'd recommend trying newer kernel, if you haven't already:
> > https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
> >
>
>
> I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
have one laptop that was totally unusable with nouveau before and
updating to 5.6.11 fixed it.
> The issue I am running into is <https://bugs.freedesktop.org/show_bug.cgi?id=99501>.
> I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
>
> I tried poking around the nouveau DDX source code, with no success.
> Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
>
> My current workaround is to either use the display without rotation or use exclusively the dGPU and connect another display to replace the laptop one. (Since using the iGPU as a xrandr sink *also* results in distortion.)
that, I guess you'll be happier :)
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
1yzBCQf7B62ZkW2H6QOnWq26/CR6akH0BY8FUJVSNaZ2hb1PBzs2icdeQdijeuIE
I0daD3nTrGvRdS63dzniTB3fKNZoq5xWpdT1jhk3vclEtO5Nn4oewXtdVLbRkIAI
7wr291bJiOvZOUxrbSQC/Agn1vnf+MHARRerAGNSScVAiCEC9VQBV38OL5pvdXe9
7/5o8Chqo266zQjcxYJgS1oAxWgtyuidD86Vj4Rk2y3Q0xD2Zk4MxnE0kb9iLvDW
M8cS8cWtoiiP7TUi0+2GHvscFUNRz27dZ29gAmyhzwKan492TfQ4dbBQQVZg+ka4
4Ip9vskBUiNc6nZ4X+poWhYgSqClyA==
=XY1p
-----END PGP SIGNATURE-----
WillyPillow
May 30, 2020, 12:45:25 AM5/30/20
to Marek Marczykowski-Górecki, qubes...@googlegroups.com
On Thursday, May 28, 2020 11:27 AM, Marek Marczykowski-Górecki <marm...@invisiblethingslab.com> wrote:
> [moving to a separate sub-thread]
>
> On Thu, May 28, 2020 at 03:18:08AM +0000, WillyPillow wrote:
>
> > On Tuesday, May 26, 2020 11:52 AM, Marek Marczykowski-Górecki marm...@invisiblethingslab.com wrote:
> >
> > > On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> > >
> > > >
> >
> > > > - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> > > > (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> > > > the proprietary drivers do not really work on Qubes.)
> > > >
> >
> > >
> >
> > > I'd recommend trying newer kernel, if you haven't already:
> > > https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
> >
> > I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
>
> Try the one from current-testing repository (5.6.x already there). I do
> have one laptop that was totally unusable with nouveau before and
> updating to 5.6.11 fixed it.
>
> > The issue I am running into is https://bugs.freedesktop.org/show_bug.cgi?id=99501.
> > I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
> > I tried poking around the nouveau DDX source code, with no success.
> > Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
> > My current workaround is to either use the display without rotation or use exclusively the dGPU and connect another display to replace the laptop one. (Since using the iGPU as a xrandr sink also results in distortion.)
> [moving to a separate sub-thread]
>
> On Thu, May 28, 2020 at 03:18:08AM +0000, WillyPillow wrote:
>
> > On Tuesday, May 26, 2020 11:52 AM, Marek Marczykowski-Górecki marm...@invisiblethingslab.com wrote:
> >
> > > On Mon, May 25, 2020 at 05:19:04PM +0000, WillyPillow wrote:
> > >
> > > >
> >
> > > > - Tried to fix a nouveau-related bug (currently to no avail, unfortunately).
> > > > (Not directly related to Qubes, but this is relevant to my use case and AFAIK
> > > > the proprietary drivers do not really work on Qubes.)
> > > >
> >
> > >
> >
> > > I'd recommend trying newer kernel, if you haven't already:
> > > https://www.qubes-os.org/doc/newer-hardware-troubleshooting/
> >
> > I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
>
> Try the one from current-testing repository (5.6.x already there). I do
> have one laptop that was totally unusable with nouveau before and
> updating to 5.6.11 fixed it.
>
> > The issue I am running into is https://bugs.freedesktop.org/show_bug.cgi?id=99501.
> > I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
> > I tried poking around the nouveau DDX source code, with no success.
> > Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
>
> This indeed may be a different issue, but if kernel update would fix
> that, I guess you'll be happier :)
For the record if anyone else is running into this: updating the kernel to 5.6.13 did not help (with either the iGPU or dGPU as the sink) in my case.
> This indeed may be a different issue, but if kernel update would fix
> that, I guess you'll be happier :)
Chris Laprise
May 30, 2020, 11:57:25 AM5/30/20
to qubes...@googlegroups.com
On 5/30/20 12:45 AM, WillyPillow wrote:
>>> I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
>>
>
>> Try the one from current-testing repository (5.6.x already there). I do
>> have one laptop that was totally unusable with nouveau before and
>> updating to 5.6.11 fixed it.
>>
>
>>> The issue I am running into is https://bugs.freedesktop.org/show_bug.cgi?id=99501.
>>> I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
>>> I tried poking around the nouveau DDX source code, with no success.
>>> Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
>>> My current workaround is to either use the display without rotation or use exclusively the dGPU and connect another display to replace the laptop one. (Since using the iGPU as a xrandr sink also results in distortion.)
>>
>
>> This indeed may be a different issue, but if kernel update would fix
>> that, I guess you'll be happier :)
>
> For the record if anyone else is running into this: updating the kernel to 5.6.13 did not help (with either the iGPU or dGPU as the sink) in my case.
An "Nvidia Graphics" logo on a computer should serve as a warning to
>>> I'm currently running kernel-latest (5.5.7), as the default kernel would crash if I connected external displays.
>>
>
>> Try the one from current-testing repository (5.6.x already there). I do
>> have one laptop that was totally unusable with nouveau before and
>> updating to 5.6.11 fixed it.
>>
>
>>> The issue I am running into is https://bugs.freedesktop.org/show_bug.cgi?id=99501.
>>> I tend to use an external display rotated vertically. But as the display outputs on my laptop are wired to the dGPU, reverse PRIME is needed, hence the issues.
>>> I tried poking around the nouveau DDX source code, with no success.
>>> Interestingly, running xorg-x11-drv-nouveau from fc31 seems to result in a slightly less distorted screen, at least at first glance.
>>> My current workaround is to either use the display without rotation or use exclusively the dGPU and connect another display to replace the laptop one. (Since using the iGPU as a xrandr sink also results in distortion.)
>>
>
>> This indeed may be a different issue, but if kernel update would fix
>> that, I guess you'll be happier :)
>
> For the record if anyone else is running into this: updating the kernel to 5.6.13 did not help (with either the iGPU or dGPU as the sink) in my case.
users of open source operating systems. Even Linus Torvalds is visibly
angry at that company.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
WillyPillow
Jun 20, 2020, 10:49:11 AM6/20/20
to Chris Laprise, Marek Marczykowski-Górecki, qubes...@googlegroups.com
Anyway, after upgrading to R4.1 with the tool mentioned by marmarek (https://github.com/fepitre/qubes-migration) and making sure that the modesetting DDX is used instead of the nouveau one, everything works like a charm.
(Previously on R4.0, forcing the modesetting DDX resulted in other issues that I'm unable to recall, but all is fine on R4.1.)
Reply all
Reply to author
Forward
0 new messages