Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

On 11/30/21 1:56 PM, Laurence Perkins wrote:
So the old inconsistency was a super-bad kind of inconsistency. 
The interfaces got named based on the order in which the devices 
were discovered.  Which, on a lot of systems, meant that every boot 
was essentially rolling the dice on a race condition.


-guppy mouth-

If you only have one device, you're fine.  If your devices consistently 
come up in the same order, you're fine.  If there's jitter though 
then things can easily get messy, and do so unexpectedly.


I guess I never really gave the renaming much thought because I almost 
always complied drivers into the kernel, which meant that they had a 
consistent ~> predictable enumeration and naming order.


The new naming scheme names devices based on where they show up 
on the bus.  This has its own issues.  It means that USB adapters 
get different names when plugged into different slots.  It means 
that adding or removing other PCI bus devices can change the bus 
address and therefore the name of your network interfaces.


Thank you for that explanation.  It describes what I witnessed perfectly.


I've seen motherboard firmware updates do the same.


Oy vey!

But, at least in theory, this inconsistency should be triggered 
by something you *know* about unless hardware is getting added and 
removed by someone else without your knowledge.


One would hope.

If you only have one interface though and tweak your hardware regularly 
then you'll probably be happier to put it back to the old naming 
scheme because with only one device it should always be eth0.


Indeed.



--
Grant. . . .
unix || die

Re: [gentoo-user] world update problem again

[Wol]

On 30/11/2021 14:18, Rich Freeman wrote:

On Tue, Nov 30, 2021 at 8:27 AM Arve Barsnes  wrote:

On Tue, 30 Nov 2021 at 14:20, John Covici  wrote:

Hi.  So, on my latest attempt at a world update today, I am getting a
crazy problem with libpng, with some packages insisting on the use
flag -apng (portage made me put it in), but other packages insisting
on the use flag apng.

Thanks in advance for any suggestions.

That is a direct conflict between chromium and firefox/thunderbird.
You can avoid it by removing the system-png flag from chromium.

That issue will probably never hit stable, and I would make a note to
revisit it in a few weeks.  The next Council agenda includes resolving
the conflict, though that isn't a guarantee it will happen.  Once the
change is settled you'll probably want to revert all your USE flag
changes to the new defaults unless you have a strong personal
preference.


I know we're encouraged to use a directory for package.use nowadays, and 
this is a perfect example why.


Create a file called "chromium" or "firefox" (whicever makes most sense 
to you), and put all the assorted flags you need to fix the issue in there.


So when you decide you want to revert all those changes, you can just 
delete that file, and bingo ...


Or just make all those changes dependent on the current version of 
chromium/firefox. So when you update you may have to re-visit the 
problem, or it may just solve itself.


Cheers,
Wol

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Rich Freeman]

On Tue, Nov 30, 2021 at 3:56 PM Laurence Perkins  wrote:
>
> If you only have one interface though and tweak your hardware regularly then 
> you'll probably be happier to put it back to the old naming scheme because 
> with only one device it should always be eth0.
>

I'm not sure if other network managers support wildcards, but with
networkd I just set the interface name to e* on single-device systems.

-- 
Rich

RE: [gentoo-user] Switching from eudev to udev, disaster.

[Laurence Perkins]

So the old inconsistency was a super-bad kind of inconsistency.  The interfaces 
got named based on the order in which the devices were discovered.  Which, on a 
lot of systems, meant that every boot was essentially rolling the dice on a 
race condition.  If you only have one device, you're fine.  If your devices 
consistently come up in the same order, you're fine.  If there's jitter though 
then things can easily get messy, and do so unexpectedly.

The new naming scheme names devices based on where they show up on the bus.  
This has its own issues.  It means that USB adapters get different names when 
plugged into different slots.  It means that adding or removing other PCI bus 
devices can change the bus address and therefore the name of your network 
interfaces.  I've seen motherboard firmware updates do the same.  But, at least 
in theory, this inconsistency should be triggered by something you *know* about 
unless hardware is getting added and removed by someone else without your 
knowledge.

If you only have one interface though and tweak your hardware regularly then 
you'll probably be happier to put it back to the old naming scheme because with 
only one device it should always be eth0.

LMP

-Original Message-
From: Grant Taylor  
Sent: Tuesday, November 30, 2021 12:34 PM
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Switching from eudev to udev, disaster.

On 11/30/21 12:58 PM, Dale wrote:
> What I noticed in dmesg is that it takes the old name, eth0 for 
> example, and then renames it to the new name.

I don't know if it's the /kernel/ that does the renaming, or not based on the 
kernel parameter, or if it's something else very early in the boot that does 
the renaming.

> Well, if one moves things around and eth0 becomes eth3 then doesn't 
> that mess up the new name as well?

My understanding is that the new name is -- supposed to be -- based off of some 
property of the device.  I assume that said property is from something akin to 
where lspci gets it's data.  Probably something exposed in /proc and / or /sys 
via the actual driver that ultimately gets feed into the renaming routine.

> That could be why you see the results you have.> It's hard to base a 
> name on something that is changing itself.

My understanding is that the new name is supposed to be completely independent 
from and not derived using the old name.  So the old naming should have no 
influence on the new name.

> It would seem to me that if they were going to change things for real, 
> they would change what the kernel names it in the beginning and it 
> uses the name it was first given based on slot or something else unique.

Agreed.  As in have the driver instantiate the device with the new name from 
the outset.

> In other words, have the kernel assign it enp2s3 or whatever when 
> booting and that is the only name it gets.

Yep.

I don't know /why/ or /where/ the failure is with the new names.  I just know 
that I have seen instability in them.  Seeing as how stability ~> 
predictability is the motivation for the rename, well, that's a failure in my 
opinion.

Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging into a 
machine than it is to have to figure out the interface name first.

That being said, I was okay with what CentOS 6.x did, where the new name was 
matched against the MAC address.  I had eth0 based on MAC for outside and eth1 
based on MAC for inside on a number of systems.



--
Grant. . . .
unix || die

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

On 11/30/21 12:58 PM, Dale wrote:
What I noticed in dmesg is that it takes the old name, eth0 for 
example, and then renames it to the new name.


I don't know if it's the /kernel/ that does the renaming, or not based 
on the kernel parameter, or if it's something else very early in the 
boot that does the renaming.


Well, if one moves things around and eth0 becomes eth3 then doesn't 
that mess up the new name as well?


My understanding is that the new name is -- supposed to be -- based off 
of some property of the device.  I assume that said property is from 
something akin to where lspci gets it's data.  Probably something 
exposed in /proc and / or /sys via the actual driver that ultimately 
gets feed into the renaming routine.


That could be why you see the results you have.> It's hard to base 
a name on something that is changing itself.


My understanding is that the new name is supposed to be completely 
independent from and not derived using the old name.  So the old naming 
should have no influence on the new name.


It would seem to me that if they were going to change things for real, 
they would change what the kernel names it in the beginning and it uses 
the name it was first given based on slot or something else unique.


Agreed.  As in have the driver instantiate the device with the new name 
from the outset.


In other words, have the kernel assign it enp2s3 or whatever when 
booting and that is the only name it gets.


Yep.

I don't know /why/ or /where/ the failure is with the new names.  I just 
know that I have seen instability in them.  Seeing as how stability ~> 
predictability is the motivation for the rename, well, that's a failure 
in my opinion.


Besides, it's a LOT easier to /just/ `tcpdump -nni eth0` when logging 
into a machine than it is to have to figure out the interface name first.


That being said, I was okay with what CentOS 6.x did, where the new name 
was matched against the MAC address.  I had eth0 based on MAC for 
outside and eth1 based on MAC for inside on a number of systems.




--
Grant. . . .
unix || die

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Dale]

Grant Taylor wrote:
> On 11/28/21 9:50 AM, Jack wrote:
>> The network name switch ... is not directly due to eudev vs. udev,
>> but to the "new" ... switch to consistent naming ... so your network
>> is probably something like enp20s2, reflecting which slot your
>> network card is physically in.
>
> Except I've had multiple instances where the supposed to be consistent
> naming is anything but consistent.  I don't know if it was a udev
> issue or something else.  But I've seen the actual address of cards in
> the system change based on what other cards are added to / removed
> from the system.  It seems as if the motherboard re-configured
> addressing with the hardware change.  E.g. NIC1 in PCIe slot A and
> NIC2 in PCIe slot C. NIC2 changed from (hypothetical) enp20s2 to
> enp16s2 when NIC1 was removed from PCIe slot A.
>
> So ... if the new naming scheme isn't consistent, then I'm not going
> to give it the time of day.  I'd rather have the older and simpler
> inconsistent naming scheme (eth#) vs the newer and more annoying
> scheme en{po}\d\d{,s}{,1,2,3}.
>
> The epiphany when is aw that the supposedly consistent names weren't
> was a real son of a REDACTED moment.
>
>> I'm pretty sure there is a kernel boot parameter which forces the old
>> way, but can't find it now, as I switched to the new naming with
>> eudev, so switching to udev didn't break anything for me.
>
> As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot
> lines (for the above reason).
>
>
>


What I noticed in dmesg is that it takes the old name, eth0 for example,
and then renames it to the new name.  Well, if one moves things around
and eth0 becomes eth3 then doesn't that mess up the new name as well? 
That could be why you see the results you have.  It's hard to base a
name on something that is changing itself.  It would seem to me that if
they were going to change things for real, they would change what the
kernel names it in the beginning and it uses the name it was first given
based on slot or something else unique.  In other words, have the kernel
assign it enp2s3 or whatever when booting and that is the only name it
gets. 

I don't change much hardware often so it doesn't affect me but I'm sure
there are people, maybe even large companies/orgs that it does and it
could be a issue for them.  It could even be a security issue if two
nics gets switched and one has a lot of security and the other doesn't. 

Either way, I'm up and running again.  Even rebuilt my backup kernels to
include the drivers this morning.  I just hope nothing comes back and
bites me later.  :/  I was a bit lost there for a while. 

Dale

:-)  :-) 

Re: [gentoo-user] Switching from eudev to udev, disaster.

[Grant Taylor]

On 11/28/21 9:50 AM, Jack wrote:
The network name switch ... is not directly due to eudev vs. udev, 
but to the "new" ... switch to consistent naming ... so your network 
is probably something like enp20s2, reflecting which slot your network 
card is physically in.


Except I've had multiple instances where the supposed to be consistent 
naming is anything but consistent.  I don't know if it was a udev issue 
or something else.  But I've seen the actual address of cards in the 
system change based on what other cards are added to / removed from the 
system.  It seems as if the motherboard re-configured addressing with 
the hardware change.  E.g. NIC1 in PCIe slot A and NIC2 in PCIe slot C. 
NIC2 changed from (hypothetical) enp20s2 to enp16s2 when NIC1 was 
removed from PCIe slot A.


So ... if the new naming scheme isn't consistent, then I'm not going to 
give it the time of day.  I'd rather have the older and simpler 
inconsistent naming scheme (eth#) vs the newer and more annoying scheme 
en{po}\d\d{,s}{,1,2,3}.


The epiphany when is aw that the supposedly consistent names weren't was 
a real son of a REDACTED moment.


I'm pretty sure there is a kernel boot parameter which forces the old 
way, but can't find it now, as I switched to the new naming with eudev, 
so switching to udev didn't break anything for me.


As Neil B. pointed out, "net.ifnames=0" is now on all my kernel boot 
lines (for the above reason).




--
Grant. . . .
unix || die

RE: [gentoo-user] Switching from eudev to udev, disaster.

[Laurence Perkins]

>> -Original Message-
>> From: tastytea  
>> Sent: Monday, November 29, 2021 9:00 PM
>> To: gentoo-user@lists.gentoo.org
>> Subject: Re: [gentoo-user] Switching from eudev to udev, disaster.
>> 
>> On 2021-11-29 22:47-0600 Dale  wrote:
>> 
>> > Now if I can figure out how to reset the list of /dev/sd* names that 
>> > are lurking about and inconsistent, that would be like striking gold.
>> >  Every time I hook up my external drive, it gets a different sd* name.  
>> > It does the same on the SD cards from my trail cameras too but I can 
>> > auto mount those.
>> 
>> I don't think it is possible to get consistent sd* names for removable 
>> media. But you could use volume labels with `tune2fs -L` or `tune.exfat -L` 
>> or `fatlabel` and then mount them via /dev/disk/by-label/*.
>> 
>> Kind regards, tastytea
>> 
>> --
>> Get my PGP key with `gpg --locate-keys tasty...@tastytea.de` or at 
>> .

Don't even need to do that if you don't care about human beings too much.  
/dev/disk/by-id has similar links based on drive model and serial number and 
/dev/disk/by-uuid I think has them by filesystem uuid.  All of those should be 
pretty consistent.

LMP

Re: [gentoo-user] world update problem again

[Rich Freeman]

On Tue, Nov 30, 2021 at 9:59 AM Matt Connell (Gmail)
 wrote:
>
> On Tue, 2021-11-30 at 09:18 -0500, Rich Freeman wrote:
> > A little background for the curious, and I'll just try to stick to the
> > factual narrative and what the main opinions are:
>
> Gentoo is in an awkward position here: as was discussed in the bug, it
> isn't simply a matter of setting libpng[-apng] by default, letting
> Mozilla bundle their own libpng, and moving on with life.  Other
> programs on Gentoo systems, built against libpng over the years with
> apng support, will suddenly *not* have it, and this situation could
> cause problems and data loss for users.
>

So now we're getting more into personal opinion.  Those same users
will suffer data loss if they open the same files on any other linux
distro or likely windows/OSX/etc versions of the same software,
because they don't use the patched version of libpng.  I certainly
don't have any objection to a heads-up news item when the change hits,
but do we REALLY want to package system libraries that have behavior
that is unique to Gentoo, and not the same as even what the upstream
devs expect?

We had a similar situation when it came out that our version of an
Etherium client (I think that was it) had some custom patches by
default, which were eventually turned off by default.  The patches
were somewhat controversial, and while I think anybody should be free
to use them (they didn't create compatibility issues with the
blockchain per se), it is surprising behavior.  This is the same
reason that we don't go putting affiliate links into search boxes on
our browsers like many distros do (which can be a significant source
of revenue).  Sure, we could patch our browsers to basically give
Gentoo a small cut anytime a user searches for anything, or charge
search engines to be the default in all our packaged browsers, but it
just isn't the way we normally do things (and those changes are IMO
more transparent anway - at least the affiliate links are).

Now, if somebody wants to run that patch by upstream libpng and it
shows signs of getting accepted then by all means hold off until that
is settled.  The goal is to stick to upstream, and we can always
release the change ahead of them (in this case more than a decade
ahead of them).

Really though this issue has been going on forever so there is no
reason to go breaking stuff until a final decision is made and we can
do an orderly transition.  I think the change is a good one, but it
would have been a good one in 2010 too.

-- 
Rich

Re: [gentoo-user] world update problem again

[Matt Connell (Gmail)]

On Tue, 2021-11-30 at 09:18 -0500, Rich Freeman wrote:
> A little background for the curious, and I'll just try to stick to the
> factual narrative and what the main opinions are:

Thank you for a good, objective breakdown.

Gentoo is in an awkward position here: as was discussed in the bug, it
isn't simply a matter of setting libpng[-apng] by default, letting
Mozilla bundle their own libpng, and moving on with life.  Other
programs on Gentoo systems, built against libpng over the years with
apng support, will suddenly *not* have it, and this situation could
cause problems and data loss for users.

I'm not a (Gentoo) dev, and I don't have strong feelings either way,
but it is an unenviable position to be in.  Regardless, I have trust
that things will be resolved reasonably in the end.

Re: [gentoo-user] world update problem again

[Rich Freeman]

On Tue, Nov 30, 2021 at 8:27 AM Arve Barsnes  wrote:
>
> On Tue, 30 Nov 2021 at 14:20, John Covici  wrote:
> >
> > Hi.  So, on my latest attempt at a world update today, I am getting a
> > crazy problem with libpng, with some packages insisting on the use
> > flag -apng (portage made me put it in), but other packages insisting
> > on the use flag apng.
> >
> > Thanks in advance for any suggestions.
>
> That is a direct conflict between chromium and firefox/thunderbird.
> You can avoid it by removing the system-png flag from chromium.

That issue will probably never hit stable, and I would make a note to
revisit it in a few weeks.  The next Council agenda includes resolving
the conflict, though that isn't a guarantee it will happen.  Once the
change is settled you'll probably want to revert all your USE flag
changes to the new defaults unless you have a strong personal
preference.

A little background for the curious, and I'll just try to stick to the
factual narrative and what the main opinions are:

Apng is an extension for the png file format that apparently adds
support for animation, and may also have other improvements.

Mozilla products ship with a bundled version of libpng that includes a
patch for apng support.  Chromium ships with a bundled version of
libpng that is just the vanilla upstream version.

The apng patch was submitted to libpng ages ago and was not accepted
at that time.  There is debate about whether it might be accepted in
the near future.

Some distros shipped the apng patch with libpng, and Gentoo has done
so by default for a while.  Over time every other distro seems to have
removed this patch, and Gentoo is the only distro patching libpng for
apng support.

Right now Gentoo's mozilla packages build against the system libpng
and not the bundled one, which means they don't work right if the apng
patch isn't in the system library.  Chromium has a use flag that
toggles whether it uses the system libpng, and if it is using the
system version it won't work unless the system libpng DOESN'T include
the apng patch.  So, without further patching (likely significant) you
can't have both packages use the system libpng at the same time.

That's basically it for the facts - I don't think any of the above is
disputed.  Now onto the implications/policy side:

Obviously everybody prefers system libraries over bundled libraries,
and everybody prefers unpatched upstream packages over patches not
likely to be accepted by upstream.  Of course, both of those cannot be
satisfied at the same time here.

Council has been asked to approve removing the apng patch by default
from libpng, using bundled libpng by default on mozilla, and using
system libpng by default on chromium.  The argument here is that
having a system library with non-standard patches that no other distro
applies could cause other issues and generally deviates from the
Gentoo way, and since at least one of the browsers will have to use
bundled libs by default it might as well be the one that uses
non-standard versions of those libs (which is already a common issue
with bundled libs in browsers - or at least it is with chromium though
in this case it is mozilla doing it).

The main counterargument is that neither option is ideal and so we
should maintain the current state, and maybe see if those apng patches
get accepted upstream.

The reason you're getting the USE flag conflicts is because chromium
has started to implement the change that they asked the council to
approve, but since they can only touch their own package we end up
with a conflict.  I doubt we'll see that make it to stable (unless
council approves the change and the other packages are modified to
eliminate the conflict) but anybody running the latest and greatest
gets to deal with the conflict in the meantime.

The gory details are in this bug - please do not comment there just to
offer opinions:
https://bugs.gentoo.org/824018

-- 
Rich

Re: [gentoo-user] world update problem again

[John Covici]

On Tue, 30 Nov 2021 08:27:14 -0500,
Arve Barsnes wrote:
> 
> On Tue, 30 Nov 2021 at 14:20, John Covici  wrote:
> >
> > Hi.  So, on my latest attempt at a world update today, I am getting a
> > crazy problem with libpng, with some packages insisting on the use
> > flag -apng (portage made me put it in), but other packages insisting
> > on the use flag apng.
> >
> > Thanks in advance for any suggestions.
> 
> That is a direct conflict between chromium and firefox/thunderbird.
> You can avoid it by removing the system-png flag from chromium.

Thanks, that did it!!  This seems to have been a new flag, not seen
before -- thanks again.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com

Re: [gentoo-user] world update problem again

[Matt Connell (Gmail)]

On Tue, 2021-11-30 at 14:27 +0100, Arve Barsnes wrote:
> > Hi.  So, on my latest attempt at a world update today, I am getting a
> > crazy problem with libpng, with some packages insisting on the use
> > flag -apng (portage made me put it in), but other packages insisting
> > on the use flag apng.
> > 
> > Thanks in advance for any suggestions.
> 
> That is a direct conflict between chromium and firefox/thunderbird.
> You can avoid it by removing the system-png flag from chromium.

This has been a hotly debated topic recently.  For more backstory, see
this bug: https://bugs.gentoo.org/824018

Re: [gentoo-user] world update problem again

[Arve Barsnes]

On Tue, 30 Nov 2021 at 14:20, John Covici  wrote:
>
> Hi.  So, on my latest attempt at a world update today, I am getting a
> crazy problem with libpng, with some packages insisting on the use
> flag -apng (portage made me put it in), but other packages insisting
> on the use flag apng.
>
> Thanks in advance for any suggestions.

That is a direct conflict between chromium and firefox/thunderbird.
You can avoid it by removing the system-png flag from chromium.

Regards,
Arve

[gentoo-user] world update problem again

[John Covici]

Hi.  So, on my latest attempt at a world update today, I am getting a
crazy problem with libpng, with some packages insisting on the use
flag -apng (portage made me put it in), but other packages insisting
on the use flag apng.

Here is the actual portage output:

Total: 232 packages (198 upgrades, 2 downgrades, 2 new, 6 in new
slots, 24 reinstalls, 2 uninstalls), Size of downloads: 3,451,440
KiB^M
Conflict: 3 blocks (all satisfied)^M
^M
!!! Multiple package instances within a single package slot have been
pulled^M
!!! into the dependency graph, resulting in a slot conflict:^M
^M
media-libs/libpng:0^M
^M
  (media-libs/libpng-1.6.37-r2:0/16::gentoo, ebuild scheduled for
  merge) USE="-apng -static-libs" ABI_X86="(64) -32 (-x32)"
  CPU_FLAGS_X86="sse" pulled in by^M
  media-libs/libpng:=[-apng] required by
 (www-client/chromium-98.0.4710.4-r1:0/dev::gentoo, ebuild
 scheduled for merge) USE="cups hangouts js-type-check official
 (pic) proprietary-codecs suid system-harfbuzz system-png
 (-component-build)\ -custom-cflags -debug (-headless) -kerberos
 -pulseaudio -screencast (-selinux) (-system-ffmpeg) -system-icu
 -vaapi -wayland -widevine" ABI_X86="(64)" L10N="am ar bg bn ca
 cs da de el en-GB es es-419 et fa fi fil fr gu he hi hr hu id it
 ja\ kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv
 sw ta te th tr uk vi zh-CN zh-TW"^M
 ^
\
\
^M
^M
  
(media-libs/libpng-1.6.37-r2:0/16::gentoo,
  installed) USE="apng 
-abi_riscv_ilp32
  -abi_riscv_ilp32d 
-abi_riscv_lp64
  -abi_riscv_lp64d -static-libs"
  ABI_X86="(64) -32 (-x32)"
  CPU_FLAGS_X86="sse" pulled in 
by^M
  
>=media-libs/libpng-1.6.35:0=[apng]
 required by
 
(www-client/firefox-94.0.2:0/94::gentoo,
 ebuild scheduled for 
merge)
 USE="clang dbus 
gmp-autoupdate
 openh264 system-av1
 system-harfbuzz 
system-icu
 system-jpeg 
system-libevent
 system-webp \-debug 
-eme-free
 -geckodriver -hardened 
-hwaccel
 -jack -lto -pgo 
-pulseaudio
 -screencast (-selinux) 
-sndio
 -system-libvpx 
-wayland -wifi"
 ABI_X86="(64)" 
L10N="-ach -af -an
 -ar -ast -az -be -bg 
-bn -br -bs
 -ca -ca-valencia -cak 
-cs -cy -da
 \-de -dsb -el -en-CA 
-en-GB -eo
 -es-AR -es-CL -es-ES 
-es-MX -et
 -eu -fa -ff -fi -fr 
-fy -ga -gd
 -gl -gn -gu -he -hi 
-hr -hsb -hu
 -hy -ia -id -is -it 
-ja -ka -kab
 -kk -km -kn -ko -lij 
-lt -lv -mk
 -mr -ms -my -nb -ne 
-nl -nn -oc
 -pa -pl -pt-B\R -pt-PT 
-rm -ro -ru
 -sco -si -sk -sl -son 
-sq -sr -sv
 -szl -ta -te -th -tl 
-tr -trs -uk
 -ur -uz -vi -xh -zh-CN 
-zh-TW"^M

   

\

\

 

[gentoo-user] Re: Trying to fix stuttering emulators (melonDS and PCSX2)

[Nikos Chantziaras]

On 27/11/2021 09:52, Jamie Getty wrote:
Hello Gentoo users. I've recently been encountering some issues running 
games on my PC. Here's video evidence of the issues I've seen: 
https://www.youtube.com/watch?v=1hNwwOOikGQ 



That video shows your PC is not fast enough to run the emulator. It only 
runs at about half speed.


What is your CPU? You can also use sys-process/htop to see how 
overloaded the primary CPU core gets. If it's at 100%, then that means 
you just need a CPU with faster single-core performance.