You are not logged in.
Anyway, I'll go have lunch then see if I can configure the stupid thing to behave.
I had a look at the thread mentioned above, and it is now marked as solved. Couple of new threads which i didn't really read through, but if you're still at it it may be worthwhile.
Cheers,
Olav
According to this thread: https://forums.linuxmint.com/viewtopic. … 3&start=20 it might be the Kernel which has to be downgraded if you insist on getting that card working properly with NVIDIAs drivers (any), (I read through it very briefly so might have missed something).
Hello
Maybe worth a try perhaps: https://www.nvidia.com/Download/Find.aspx?lang=en-uk, downgrade driver version?
Olav
PS
What desktop environment are you on by the way?
Hello
Just for fun I tested alsamixergui, it runs just fine here, but I don't like it much; it's far better to use the cli version, alsamixer, in my opinion (if any of those, of course). I'm on KDE though DE choice should not have any impact in this regard.
PS
HoaS
Btw pure ALSA should work just fine unless you're video conferencing. I don't use any sound servers and everything works, even under systemd.
This is not true in general. It depends whether the software is built explicitly towards having PA/PW (sound-servers most relevant in this case I guess) etc. or not; and whether or not you manage to get APulse to work as a replacement API. During lock-down I set up Zoom for online tutorials, no PA involved if I remember correctly.
Many other tools work as well, QTox and JAMI are those I have used fairly recently.
Cheers,
Olav
Audio-wise there is nothing PulseAudio or PipeWire can do which ALSA can't, they totally depend on it; the potentiality of PA and PW are limited by ALSA's.
PA and PW act as sound-servers and wish to route every audio instance through (whichever chosen) them (including OSSs btw), so to have a uniformed interface/framework for users as well as APIs for programmers' software to interact with. Dealing (users) with multiple audio-devices, concurrent I/O audio events, various and different audio libraries simultaneously, various frequencies ... and so on; this is not always easy when interacting 'directly' with ALSA as it may involve creating and/or editing configuration files which may end up very complex, say ~,asoundrc; PA (I guess) was an effort to address this moving forwards towards user-friendliness and, as mentioned, consistency.
For me ALSA without any intermediate layer works well; however, as things has evolved, more and more software are written expecting a sound-server dealing with the various applications' audio-instances in mind, hence decrease in support for ALSA 'only'. APulse seems to work alright though(?).
As I used to work on and with DAWs, for me, therefore! , PA (and probably PW which I don't know) is just a bloody potter about interfering (JACK) and drawing resources from the system. I ditched PA early on so I should be a bit humble with regard the present status (all though not quite), but however you look at it, it basically is a layer which provides no extra potential, just an easier configuration and management path.
Olav
Well, best of luck creating audio with it
Cheers,
Olav
I have now achieved what I wanted to do, i.e. I can change between languages within the individual GTK package; just to mention, I tested languages which weren't enabled on the system, en_GB and nn_NO are the system languages, and they worked as well.
olav@DDAmt:~$ gsettings set org.gnome.system.locale region en_GB.UTF-8
I find this very strange but setting a specific language code with the command above changed everything. The «org.gnome.system.locale» string used to be empty, as shown in an earlier post, setting it to en.GB, or any language-code other than empty I presume, just made it possible to swap between them. Furthermore, even though I had set en_GB as default language (system-wide and KDE locales), after a re-login GIMP started using the nn_NO.
I'll stop now, too much speculations and I haven't got the energy nor the capacity probably to dig deeper to find the, obvious, logic behind this behaviour.
One thing I'm quite sure of though is that the output of «gsettings get org.gnome.system.locale region» command can't show an empty string, for whatever reason, if it does you, or at least I wasn't (on two different computers in fact), won't be able to change the locale setting for GTK apps in accordance with your preference in KDE nor swap between translations from within the individual applications, GIMP and Inkscape tested in this case.
Some premises seeing the above to be (fairly)valid:
- Devuan Beowulf
- KDE
- everything up to date
- no repositories other than the official ones (apart from some application specific repoes which should not interfere with the system in any way)
Thanks for your help Head_on_a Stick!
(you have my vote if you wish to have it back on your shoulders)
Olav
Hi
Sorry, was a bit hasty and just presumed you used KDE as your environment based on all the pinned packages.
I don't know much about TDE but remember having had similar issues to yours when GTK wasn't integrated with KDE, i.e. the GTK-KDE module (the names and procedures have changed with KDE development) had to be installed and I would then be able to change/enable the GTK (uniformly) themes within the KDEs «System Settings → Application Style ... » dialogue.
Probably not relevant in your case though.
Cheers,
Olav
Okay
To me it seems like some KDE, GTK integration package might be missing. I may be on thin ice here and I'm also curious to why so many KDE packages are pinned?
Is this one installed?
«KDE configuration module for GTK+ 2.x and GTK+ 3.x styles selection»
And please use code tags rather than quote tags when posting terminal output.
OK, I'll try to remember that.
And thanks so far!
By the way, what is the syntax?
Where should I put in the language code to use?
I was a bit confused by this output:
olav@DDAmt:~$ gsettings set org.gnome.system.locale region
Usage:
gsettings [--schemadir SCHEMADIR] set SCHEMA[:PATH] KEY VALUE
Set the value of KEY to VALUE
Arguments:
SCHEMADIR A directory to search for additional schemas
SCHEMA The name of the schema
PATH The path, for relocatable schemas
KEY The key within the schema
VALUE The value to set
It says nothing in fact
olav@DDAmt:~$ gsettings get org.gnome.system.locale region
''
[color=green]olav@DDAmt:~$ locale
[/color]locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=nn_NO.UTF-8
LANGUAGE=en_GB
LC_CTYPE="nn_NO.UTF-8"
LC_NUMERIC="nn_NO.UTF-8"
LC_TIME="nn_NO.UTF-8"
LC_COLLATE="nn_NO.UTF-8"
LC_MONETARY="nn_NO.UTF-8"
LC_MESSAGES="nn_NO.UTF-8"
LC_PAPER="nn_NO.UTF-8"
LC_NAME="nn_NO.UTF-8"
LC_ADDRESS="nn_NO.UTF-8"
LC_TELEPHONE="nn_NO.UTF-8"
LC_MEASUREMENT="nn_NO.UTF-8"
LC_IDENTIFICATION="nn_NO.UTF-8"
LC_ALL=
[color=green]olav@DDAmt:~$ [/color]
This output is from after disabling «nn_NO.UTF-8» locally (KDE system settings) as well.
Just a final note, «kde-l10n-nn» wasn't even installed when I started this thread, so probably a reinstall, not a dist-upgrade; I haven't used this computer for a while and can't remember precisely.
I have two locales enabled: en_GB and nn_NO, in that priority order.
[color=green]olav@DDAmt:~$ locale -a[/color]
C
C.UTF-8
en_GB.utf8
nn_NO.utf8
POSIX
[color=green]olav@DDAmt:~$ echo $LANG[/color]
nn_NO.UTF-8
[/quote]
As you may see, the latter command shows just Norwegian (nynorsk) as available.
If I disable nn_NO (dpkg-reconfigure locales), some of the «LC_ ...» parameters will state «not available» (those not set specifically as appropriate from a Norwegian and personal point of view: monetary, numeric, time etc.).
[quote][color=green]olav@DDAmt:~$ locale[/color]
LANG=nn_NO.UTF-8
LANGUAGE=en_GB:nn
LC_CTYPE="nn_NO.UTF-8"
LC_NUMERIC="nn_NO.UTF-8"
LC_TIME="nn_NO.UTF-8"
LC_COLLATE="nn_NO.UTF-8"
LC_MONETARY="nn_NO.UTF-8"
LC_MESSAGES="nn_NO.UTF-8"
LC_PAPER="nn_NO.UTF-8"
LC_NAME="nn_NO.UTF-8"
LC_ADDRESS="nn_NO.UTF-8"
LC_TELEPHONE="nn_NO.UTF-8"
LC_MEASUREMENT="nn_NO.UTF-8"
LC_IDENTIFICATION="nn_NO.UTF-8"
LC_ALL=
[color=green]olav@DDAmt:~$ locale[/color]
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=nn_NO.UTF-8
LANGUAGE=en_GB:nn
LC_CTYPE="nn_NO.UTF-8"
LC_NUMERIC="nn_NO.UTF-8"
LC_TIME="nn_NO.UTF-8"
LC_COLLATE="nn_NO.UTF-8"
LC_MONETARY="nn_NO.UTF-8"
LC_MESSAGES="nn_NO.UTF-8"
LC_PAPER="nn_NO.UTF-8"
LC_NAME="nn_NO.UTF-8"
LC_ADDRESS="nn_NO.UTF-8"
LC_TELEPHONE="nn_NO.UTF-8"
LC_MEASUREMENT="nn_NO.UTF-8"
LC_IDENTIFICATION="nn_NO.UTF-8"
LC_ALL=
As I see it, this has to be some locale settings stuck from before a dist-upgrade/reinstall.
Thanks a lot, and there are some progress, though not in the expected direction
I'll come back to it whether or not I manage to get the result I want; in the latter case, it might be helpful for others.
Cheers,
Olav
Hello everyone.
I seem to be unable to change locales (interface) on some applications, GIMP, Inkscape are the ones tested for now.
I am running on KDE and KDE apps seems to function fine in this regard so I guess it has to do with GTK applications; it didn't use to be like this before though.
All the appropriate language files are present but the programmes seem unable to read them; GIMP, for instance, regards the present of the lang-file but after a restart the language stays the same.
Any tips on this one?
Cheers,
Olav
Fond of you all!
Thanks for doing Devuan.
Cheers,
Olav
Hei Altoid.
Could this be related to having replaced consolekit with elogind?
I have not seen or noticed any adverse symptoms.
I went through the same procedure as you did, upgraded from ASCII to Beowulf; so, I don't think it has to do with that.
KWallet is working but, if I remember correctly, I had some issues initially; think I started from scratch and deleted every (user) kwallet associated files and repopulated the walletDB.
Not a good answer, and no proper solution, but that's how I believe I did manage to get the KWallet back working.
If you investigate further, which I didn't, you'll probably find a better way; the meaning of this reply was to state that it definitely may work!
Best of luck,
Olav
Thanks:)
Wait for tuxd3v's input then, to see if it's the right one.
Hello all!
What would be the right choice of architecture to download for an ARM Cortex-A9?
Cheers,
Olav
PS
All my current computers runs fine on Devuan!
Did not mean to have focus away from you're issue dice, sorry about that!
F_Sauce wrote:Hei Andy, I'll check, back soon.
Oh noes, F_Sauce might be caught in a time warp.
I'm a bit nostalgic, used to play (occasional «now» as well) some old games on it.
CPU: https://en.wikipedia.org/wiki/Pentium_III, still running fine!
GPU: (PCI) https://en.wikipedia.org/wiki/GeForce_FX_series.
Upgraded (spinning) hard-drives, but with 1999 original mother-board and RAM.
If you are very interested Andy, I will give you all the current hardware details; I booted it up last probably a year ago, no trouble I presume!
When I first installed Linux and SuSE 9.1 ... , it was newer hardware; it was a Dell from 2002/3 with a Pentium 4 CPU, I threw away Windows and started
Cheers,
Olav
Hei Andy, I'll check, back soon.