Linux-kysymyksiä & yleistä keskustelua Linuxista

Tämä on just se ongelma. En tähän hätään muista, miten ton sai korjattua, mutta löytyi kohtuu helposti googlettamalla oikea kohta asetustiedostoista. Kts. linkit lopussa.

Tällä ongelmalla ei ole mitään tekemistä Pipewiren kanssa, vaan sama ongelma tulee myös Pulseaudion kanssa, jos se on asetettu siten että se laittaa äänilaitteet virransäästötilaan (minulla nimenomaan oli tämä ongelma Pulseaudiolla). Distribuution oletusasetuksilla on hyvinkin paljon asian kanssa tekemistä, ja nyt vain on niin että aiemmalla postaajalla distribuutio (ilmeisesti) Pulseaudiolla oletuksena ei käytä em. virransäästöä, kun taas Pipewirellä käyttää.

EDIT: Asetus kannattaa ehkä jopa pitää päällä läppäreillä, vaikka aiheuttaisi poksumista, mutta ehkä säätää aikaa pidemmäksi, jos voi (ainakin PipeWirellä voi, Pulseaudiolla ei?). Pöytäkoneilla tuskin on tällä virransäästöllä mitään väliä, jatkuva poksuminen aina esim. äänimerkkiä ennen ja sen jälkeen sen sijaan on hyvin rasittavaa.

EDIT: Mahdollisesti näistä linkeistä apua - mutta kannattaa tarkistaa oma distribuution dokumentaatio, voi olla että homma toimii kuten Archissa tai sitten enemmän tai vähemmän erillä tapaa: PulseAudio/Troubleshooting - ArchWiki ja PipeWire - ArchWiki
Kiitos avusta. Näissä on vaan se ongelma, että pitäisi ensiksi keksiä kaikki mahdolliset konffit noihin tiedostoihin jostain. Mulla on 2015 asti päivitetty Kubuntu ja Pipewire tuli ehkä pari päivitystä sitten. /etc/pipewire/media-session.d/ :ssä ei ole yhtikäs mitään. Eli joutuu lukemaan manuaaleja, että mitä niihin pitää tunkea jos ei ole valmiita pohjia missään, niin menee vaan rutosti aikaa.
 
Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?
 
Kiitos avusta. Näissä on vaan se ongelma, että pitäisi ensiksi keksiä kaikki mahdolliset konffit noihin tiedostoihin jostain. Mulla on 2015 asti päivitetty Kubuntu ja Pipewire tuli ehkä pari päivitystä sitten. /etc/pipewire/media-session.d/ :ssä ei ole yhtikäs mitään. Eli joutuu lukemaan manuaaleja, että mitä niihin pitää tunkea jos ei ole valmiita pohjia missään, niin menee vaan rutosti aikaa.

Tuo mainitsemasi hakemisto viittaa vanhaan pipewire-media-sessioniin, joka oli PW:n aikaisempi sessionhallinta ja jonka kehitys loppui jokunen vuosi sitten kun WirePlumber korvasi sen. Ennen enempää perehtymistä kannattanee varmistaa että kyseessä ei ole jäännös vanhasta versiosta ja että Ubuntukin on jo siirtynyt WirePlumberin käyttöön.

Suspendin disabloimiseen löytyy pari eri tapaa PipeWire FAQista Troubleshooting · Wiki · PipeWire / pipewire · GitLab ja WirePlumberille lyhyt opas Disable Pipewire Suspend on Idle to avoid audio pops, delays, and white noise
 
Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

GRUB kun on käytössä, niin voit lisätä numeron 3 kernelin boot parametreihin editoimalla GRUB-bootmenussa, niin kone käynnistyy suoraan komentoriville ilman grafiikkaa. Sen jälkeen vaan logeja kattelemaan missä vika.

[edit] Toi on tosin vain arvailua näillä tiedoilla. Pitäis saada enemmän dataa tapahtuneesta logien kautta. Toi, et jätetään päivityksiä odottamaan, johtuu ainakin Ubuntulla siitä, että kyseiseinen päivitys, kyseisellä käyttisversiolla on johtanyt ongelmiin X-prosentilla päivityksen asentajista, jonka vuoksi sen jakelu on keskeytetty kyseiselle käyttisversiolle.

Toi tuhatkunta on kyllä niin julmeton määrä, et kyse ei taida olla tuosta...
 
Viimeksi muokattu:
Semmonen huomio, että noi ritinät ja poksahdukset ei tallennu Pipewire FAQ:ssa neuvottuun audio data dumpiin. Koneella kuunellessa tietenkin kuuluu noita (ja joka kerta eri kohassa), mutta kun tuo siirti puhelimeen ja sillä kuunteli niin äänessä ei ollu mitään ylimäärästä häiriötä.
Edit: niin eikä niitä kuulu samaisen Ubuntun asenustikulta löytyvästä puhtaasta asennuksesta.
 
Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

Vastausta en osaa antaa mutta ittellä on jo yli 10v takaa aika samanlainen kokemus debianin kanssa. Se sitten jäikin viimeiseksi kokeiluksi kyseisen distron kanssa.
 
Päätinpä sitten eilen illalla päivittää Debianin komennoilla apt update ja apt full-upgrade.

Alkuun vaikutti toimivan hyvin ja versioksi muuttui uusin 12.5, mutta sitten tapahtui jotain mystistä. Kun yritin normaalisti päivittää apt upgradella, niin tuhatkunta pakettia jäi "odottamaan päivitystä".

Noh, kone toimi normaalisti, joten jatkoin puuhastelua ja lopulta sammutin koneen. Kun seuraavan kerran yritin käynnistää, tuli eteen vain musta ruutu. Ilmeisesti joku/jotkut näistä paketeista olisi ollut tarpeen päivittää vaikka väkisin... Ei auttaneet mitkään näppäinkomennot, että olisi päässyt pelkälle komentoriville ilman graafista käyttöliittymää.

Kertaalleen sain bootattua grubin kautta valitsemalla vanhan kernelin, mutta kun siellä sit päivittelin systeemiä, lakkasi sekin toimimasta...

Sain kuitenkin oleelliset tiedostot talteen toiselle osiolle, joten kikkailun välttämiseksi vedin sileäksi koko käyttöjärjestelmäosion ja asensin tikulta uuden version. Nyt toimii taas.

Jatkon varalta, mikähän tuossa meni vikaan ja miten version sais jatkossa päivitettyä uuteen ilman vastaavaa säätöä?

Debian on yksi eniten vakaimmista distroista, näin melkein 30-vuoden kokemuksella sanottuna. Stable releasin pitäisi päivittyä aina ongelmitta. Mutta suosittelen ottamaan niitä varmuuskopioita levystä ja tiedostoista. Suosittelen varmuuskopiomaan käyttöjärjestelmän esim. Clonezillalla aina silloin tällöin niin välttyy isommilta asennus ruljansseilta.
 
Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.
 
Mistä johtuu, että Ubuntu 24.04:ssä "dmesg --ctime" näyttää kellonaikoja, jotka on noin 11,5 tuntia edellä verrattuna oikeaan aikaan (jonka mm. "date" näyttää)?

Joskus kauan sitten dmesg:n näyttämät kellonajat oli ihan pielessä, mutta se johtui ilmeisesti siitä, että se kello pysähtyi aina kun koneen laittoi lepotilaan tms., mutta tuo bugi korjattin jo aikoja sitten ja esim. Ubuntu 20.04:ssä ajat oli aina oikein.
Kyllä tuo mulla ainakin näyttää ihan oikeata aikaa.
 
Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?
 
Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?
En tiedä saisiko tuon prioriteettia heti prosessin käynnistyksessä säädettyä (varmaan onnistuisi jostain palvelun asetustiedostosta) mutta ainakin käynnissä olevan prosessin prioriteettia voi muokata renice-komennolla. Ja tuon renice-komennon sopivilla parametreilla saisi varmaan johonkin koneen startup-skriptiin laitettua.

Ilmeisesti pipewiren konffissa on joku "nice.level" -parametri jolla tuota voisi säätää mutta itsellä ei ole kokemusta.
 
Taisi löytyä viimein ratkasu tohon ääni ongelmaan ja näyttäs ratkeavan nostamalla pipewiren prosessin prioritettia.
Mutta kysymys kuuluu, miten tämän saa pysyvästi korkeammalle prioriteetille?
Kun esim. system monitorista tai vaikka topissa tota saa käsin muutettua kyllä, mutta miten ton sais pysyvästi isommalle, että ei tarviis joka buutissa ruuvata tota?

Ei ole tullut Ubuntujen kanssa tolskattua Pipewire-aikakaudella, mutta tuon pitäisi toimia ilman että tarvitsee käsin härppiä. Pipewire asettaa itse prioritynsä korkeammalle jos tarvittavat oikeudet ovat kunnossa, tai vaihtoehtoisesti pyytää sitä RTKitiltä DBusin kautta. Jälkimmäisen tavan vaatimuksista ei tietoa, mutta ensiksi mainittu on ainakin muutamassa muussa distrossa sidottu pipewire groupiin. Eli käyttäjän jolla halutaan pipewireä käyttää tulee olla tuossa groupissa.

Kannattaa kurkistaa onko pipewiren paketissa mukana /etc/security/limits.d/ hakemistoon tulevaa confia, jos tulee niin siitä pitäisi selvitä group johon käyttäjä lisäämällä homman pitäisi suttaantua. Jos sitä ei tule niin kenties Ubuntulla on joku eri tapa tehdä tuo.

Esim Fedorasta pipewire-paketista löytyy /etc/security/limits.d/25-pw-rlimits.conf jossa:

Koodi:
@pipewire   - rtprio  70
@pipewire   - nice    -19
@pipewire   - memlock 4194304
 
Eipä se tuo käsin prioritetin nosto auttanu sittenkään...kahta kauheempana rätisee. :(
Kokeilaan käyttäjän lisäämistä vielä tonne pipewire ryhmään....tosin minusta minä tämänkin koitin jo aikasemmin.
Semmosen huomion tein kans, kun ihmettelin tuota system monitoria, että kun ääni rätisee ja poksuu niin niin pipewire-pulse prosessi hyppii sleeping ja running väliä minusta jatkuvasti. Sillon kun audio toimii niin toi pysyy running tilassa koko ajan niin pitkään kuin ääntä soittaa.
 
Eipä se tuo käsin prioritetin nosto auttanu sittenkään...kahta kauheempana rätisee. :(
Kokeilaan käyttäjän lisäämistä vielä tonne pipewire ryhmään....tosin minusta minä tämänkin koitin jo aikasemmin.
Semmosen huomion tein kans, kun ihmettelin tuota system monitoria, että kun ääni rätisee ja poksuu niin niin pipewire-pulse prosessi hyppii sleeping ja running väliä minusta jatkuvasti. Sillon kun audio toimii niin toi pysyy running tilassa koko ajan niin pitkään kuin ääntä soittaa.

Erikoinen tapaus kyllä. Jotenkin kai pitäisi pystyä haarukoimaan että mitä tuossa on eri tavalla silloin kun se toimii ongelmitta verrattuna rätinään. Onko jokin tietty softa jonka äänet rätisevät? Ja onko se joka kerta sama softa? Tai onko useampi aktiivinen ääntä tuottava softa käynnissä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. pw-top tai pw-dump työkalujen ulosantia äänten toimiessa ja rätistessä. Jälkimmäinen tosin tuuttaa pitkän JSONin jonka vertaaminen voi vaatia toisenkin kupillisen kahvia.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.
 
Mint Cinnamonin jälkeen kokeilin Matea ja mikäs sen tehtäväpalkkia mahtaa vaivata kun välillä ei voi klikata toista tehtäväpalkissa auki olevaa ikkunaa/ohjelmaa esille, vaan se alkaa vilkuttamaan sillä hetkellä esillä olevaa ikkunaa/ohjelmaa tehtäväpalkissa. Kun klikkaan sitä niin se esillä oleva ikkuna minimoituu ja vasta sen jälkeen voin klikkailla muita luukkuja tehtäväpalkissa. Tilanne missä tämän saa varmasti ainakin itsellä aina toistettua on pitää ohjelma A esillä ja klikata starttivalikko auki, minkä jälkeen en voi sen jälkeen suoraan klikata ohjelmaa B tehtäväpalkissa esille vaan pitää klikata ohjelmaa A ensin jolloin se minimoituu. Hivenen kankealta ja epäloogiselta tuntuu.

Edit: Jahas, nähtävästi johtui Window managerin vaihdosta oletuksen Marco + compositing -> Marco + compton minkä yksi tuninkisivu neuvoi vaihtamaan. Typerä tuunausneuvo kun huonontaa käytettävyyttä.
 
Viimeksi muokattu:
Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi
 
Viimeksi muokattu:
Mikähän on vika? Kone on vanha 4770K ja siinä Debian (uusin, päivitetty) ja Virtualbox ja siellä Windows 11, missä ajoin sitä Microsoftin virustorjunnan full scannia. Sain kolme kertaa koneen buuttaamaan hallitsemattomasti, eli jotenkin rasitukseen tämä

.. tämä jo ratkesi

Mikä se ratkaisu oli?
 
Erikoinen tapaus kyllä. Jotenkin kai pitäisi pystyä haarukoimaan että mitä tuossa on eri tavalla silloin kun se toimii ongelmitta verrattuna rätinään. Onko jokin tietty softa jonka äänet rätisevät? Ja onko se joka kerta sama softa? Tai onko useampi aktiivinen ääntä tuottava softa käynnissä?

Jotakin vinkkiä voisi saada myös jos vertaa esim. pw-top tai pw-dump työkalujen ulosantia äänten toimiessa ja rätistessä. Jälkimmäinen tosin tuuttaa pitkän JSONin jonka vertaaminen voi vaatia toisenkin kupillisen kahvia.


Hämärä flashback tuli miten vuosia sitten painiskelin vastaavan ongelman kanssa, satunnaisesti äänentoistossa oli epämääräisiä napsumisia ilman että mikään ilmiselvä olisi muuttunut välissä. Parin spirtismisession jälkeen hoksasin että äänilaitteen sample rate oli eri tapausten välillä.

Ongelman ilmetessä oli käynnissä useampi ääntä tuottava softa (en muista mitkä), ja riippuen missä järjestyksessä softat avasivat streamin ongelma joko tuli tai ei tullut. Toiston sample rate asetettiin ensimmäisen streamin mukaan, jos softa X oli ekana, niin sample rateksi tuli 48kHz ja toisen softan toisto poksui. Jos softa Y kerkesi ensin, sample rate oli 44.1kHz ja äänet toimivat täydellisesti.

En muista enää löytyikö tähän oikeakin ratkaisu vai päädyinkö johonkin workaroundiin, mutta ei tuota ole tapahtunutkaan vuosikausiin. Saattoi jopa olla kun vielä käytin PulseAudiota, joten ei välttämättä edes liity juuri sinun ongelmaasi.
Hmm...
Ulostulon sample rate näyttäs olevan mulla kait väärä?
pw-top_screenshot.png

Eikös tuon pitäs olla sama 44.1kHz kuin tolla lähteellä eli VLC:lla?
Tosin rätinään toi ei vaikuta, kun Firefox ja esim. Youtube videot ovat 48kHz ja silloin toi lähde on myös 48000 mutta silti rätisee. Sitähän en tosin tiiä onko Youtube videooiden audio raidat sitten 48kHz oikeasti...
 
Mikä se ratkaisu oli?

Ne core multiplierit oli sittenkin liian suuret 44,43,42,41 eli joku oli niitä säätänyt joskus, kun tuonhan piti olla 3,5 GHz ja "turbo" 3,9 GHz. Pienensin kaikkia yhdellä niin sitten sain ajeltua virustarkistukset (yms. näennäispuuhat) läpi. Ajoin myös memtest:iä 20 minuuttia. Muistista ei löytynyt mitään vikaa tuolla ajalla, joten en tiedä lopulta mihin kaatui, muuta kuin "liian korkeaan multiplieriin".
 
Hmm...
Ulostulon sample rate näyttäs olevan mulla kait väärä?
pw-top_screenshot.png

Eikös tuon pitäs olla sama 44.1kHz kuin tolla lähteellä eli VLC:lla?
Tosin rätinään toi ei vaikuta, kun Firefox ja esim. Youtube videot ovat 48kHz ja silloin toi lähde on myös 48000 mutta silti rätisee. Sitähän en tosin tiiä onko Youtube videooiden audio raidat sitten 48kHz oikeasti...

Ei tuolla pitäisi normaalisti olla merkitystä, vaikka olisi yhtä aikaa useampi lähde eri sample ratea puskemassa.

Tähän tapaan:
1715184651515.png
 
Mistä johtuu USB-liitäntäisessä headsetissa mikin pätkiminen?
Samoihin aikoihin kernel.log täyttyy "kernel: retire_capture_urb: 108 callbacks suppressed"(toi 108 numero vaihtelee ja ei ole joka rivillä sama) virheistä.
Edit niin ja pystyykö snap paketoidusta Discordista estämään jotenkin mikin käytön täysin?
Kun nyt jos on Teams kokous käynnissä ja myös discord auki niin aina headsetin yhteyden pätkästessä Discord nappaa mikin eikä se enää Teamsissa toimi.
 
Mistä johtuu USB-liitäntäisessä headsetissa mikin pätkiminen?
Samoihin aikoihin kernel.log täyttyy "kernel: retire_capture_urb: 108 callbacks suppressed"(toi 108 numero vaihtelee ja ei ole joka rivillä sama) virheistä.

Tuo ei varsinaisesti ole virhe, kertoo vain että kernelin retire_capture_urb funktio haluaa logittaa enemmän mitä rate limit antaa myöten ja että 108 logiviestiä on suppressoitu.

Mahdollisesti nuo estetyt viestit kertoisi virhetilanteesta, mutta ne pitäisi ensin saada näkyville.
 
Tuo ei varsinaisesti ole virhe, kertoo vain että kernelin retire_capture_urb funktio haluaa logittaa enemmän mitä rate limit antaa myöten ja että 108 logiviestiä on suppressoitu.

Mahdollisesti nuo estetyt viestit kertoisi virhetilanteesta, mutta ne pitäisi ensin saada näkyville.
Mitehän nuo sitten saisi näkyville?
Tai mistähän lähtisi purkamaan tota ongelmaa?
 
Mitehän nuo sitten saisi näkyville?
Tai mistähän lähtisi purkamaan tota ongelmaa?

Ehkä voisi koittaa ottaa ratelimiting pois päältä ja sen jälkeen toistaa ongelma. Ajossa olevan kernelin ratelimit asetusta pitäisi voida muuttaa sysfs:n kautta kirjoittamalla kernel/printk_ratelimit:een 0, esim. sysctl -w kernel.printk_ratelimit=0

Muutoin vähän hankala sanoa näillä tiedoilla. Näkyykö journalissa tai dmesg:issä mitään mikä voisi asiaan liittyä ongelman ilmaantumishetken ympärillä?
 
Mikähän bluetooth usb-dongle toimisi luotettavasti linuxissa? HP:n pöytäkoneella ja fedoralla on lähes mahdotonta saada bluetooth-kuulokkeet yhdistettyä. Jos kuulokkeet pitää aina samassa koneessa kiinni eikä koskaan yhdistä niitä muualle, niin toimii kohtalaisesti. Muussa tapauksessa pitää aina parittaa uudelleen ja se on yhtä helvettiä, koska laitetta joko ei löydy, tai sitten fedora yhdistää laitteen minkä paritus on jo moneen kertaan purettu (!?!?). Ainoa tapa mikä toimii jotenkin, on ajaa bluetooth-palvelu alas, laittaa kuulokkeet paritustilaan, käynnistää bluetooth-palvelu ja yrittää sitten paritusta. Asiaa ei helpota se, että kuulokkeiden saaminen paritustilaan onnistuu ehkä yhdellä kertaa viidestä, mutta ei kai uutena lähemmäs 300 euroa maksaneilta sonyn kuulokkeilta voi mahdottomia vaatiakaan :P

En ole kylläkään varma onko vika bluetooth-piirissä vai eikö bluetooth vaan toimi linuxissa tuon paremmin. Äsken piti katsella 20min rust-video loppuun, mutta se 20min meni kuulokkeiden paritukseen.
 
Mikähän bluetooth usb-dongle toimisi luotettavasti linuxissa? HP:n pöytäkoneella ja fedoralla on lähes mahdotonta saada bluetooth-kuulokkeet yhdistettyä. Jos kuulokkeet pitää aina samassa koneessa kiinni eikä koskaan yhdistä niitä muualle, niin toimii kohtalaisesti. Muussa tapauksessa pitää aina parittaa uudelleen ja se on yhtä helvettiä, koska laitetta joko ei löydy, tai sitten fedora yhdistää laitteen minkä paritus on jo moneen kertaan purettu (!?!?). Ainoa tapa mikä toimii jotenkin, on ajaa bluetooth-palvelu alas, laittaa kuulokkeet paritustilaan, käynnistää bluetooth-palvelu ja yrittää sitten paritusta. Asiaa ei helpota se, että kuulokkeiden saaminen paritustilaan onnistuu ehkä yhdellä kertaa viidestä, mutta ei kai uutena lähemmäs 300 euroa maksaneilta sonyn kuulokkeilta voi mahdottomia vaatiakaan :p

En ole kylläkään varma onko vika bluetooth-piirissä vai eikö bluetooth vaan toimi linuxissa tuon paremmin. Äsken piti katsella 20min rust-video loppuun, mutta se 20min meni kuulokkeiden paritukseen.
Käyttääkös se fedora pulseaudiota vai pipewire? Alunperin vaihdoin pulseaudiosta pipewireen juuri sen takia kun bluetooth vehkeitä ei saanut PA:lla toimimaan kunnolla vaikka kuin rukoili ja hinkkasi. Pipewirellä ei ole ollut enää mitään onglemia ja joissain distroissa se tulee jo oletuksena tai ainakin voi valita asennusvaiheessa.
 
Melko tärkeitä päiviä Nvidia Wayland käyttäjän näkökantista tällä viikolla.

XWayland 24.1 julkaistu muutama tunti sitten, explicit sync tuki nyt mukana. Löytyy jo Arch extra-testing reposta.

KDE (kwin) käyttäjille valmiiksi AURista cherry pickattu explicit sync tuki, jos ei jaksa odotella Plasma 6.1 ensi kuulle.

Itse Nvidian 555 beta-ajurit, joissa explicit sync pitäisi tänään tulla jossain vaiheessa. Nvidia devaajan mukaan suunnitelmat muuttui, ei ajuria tänään.

Tänään piti myös tulla Mesa 24.1 explicit sync tuella, mutta viivästystä pukkaa ja 24.1-rc4 sen sijaan toistaiseksi.
 
Viimeksi muokattu:
Jatketaas vielä tuota mun Pipewiren poksumis onglemaa ja sen ihmettelyä.
Semmosen haivainnon tein tässä, että toi poksuminen ja rätinä vaimenee mitä korkeampi taajuus on, mutta ite poksahduksen taajuus on minusta aikalailla sama. Pink ja white noisella sitä en havaitse, mutta brown noisella kyllä.
 
Käyttääkös se fedora pulseaudiota vai pipewire? Alunperin vaihdoin pulseaudiosta pipewireen juuri sen takia kun bluetooth vehkeitä ei saanut PA:lla toimimaan kunnolla vaikka kuin rukoili ja hinkkasi. Pipewirellä ei ole ollut enää mitään onglemia ja joissain distroissa se tulee jo oletuksena tai ainakin voi valita asennusvaiheessa.

Pipewireä käyttää. Hyvä puoli on toki se, että kun kuulokkeet on kerran saanut paritettua ne kyllä toimii ja jopa yhdistyy automaattisesti, kunhan niitä ei vaan välillä käytä muilla laitteilla.

OT Olen kyllä muutenkin välillä harkinnut jonkinlaista bluetooth-lähetintä mikä kytkettäisiin kuulokeliitäntään eli tavallaan muutettaisiin bluetooth-kuulokkeet langalliseksi, koska bluetooth-laitteiden kytkeminen on muutenkin niin hankalaa. Esim. töllöön kytkeminen vaatii niin monen valikon selaamista ja odottelua, että sitä ei yleensä jaksa tehdä, jos vaihtoehtona on langallisten kuulokkeiden kytkeminen ps4 padiin. :P /OT
 
Tuli uusi ongelma vastaan nvidialla. Kone hidastuu satunnaisesti suspend modesta herättäessä siten, että kaikki graafinen softa pyörii noin 1fps, kun käytössä on xorg. Lisähauskuutena päivitin fedoran (40) ja bootin jälkeen kone jumiutui fedora logoon, vmp.

Tuota xwayland 24.1:tä odotellessa, jos sitten voisi siirtyä waylandiin.
 
Kwin on kuulemmat hajonnut X11 käyttäjille jossain viime viikon päivityksessä, korjaus kyllä käsittääkseni pitäisi olla jo pukattu ulos.

Tuli tänään asenneltua työpöytäkoneellekin F40 KDE vara-SSD:lle. Laitoin sisään nuo nykyiset Nvidian ajurit ilman explicit sync tukea, jotta voi sitten verrata kunhan 555 ajurit joskus vihdoin saapuu. Jotkut softat toimii hienosti, jotkut on puolestaan taas kohtauksen aiheuttavia, esim Steam. Itse pelit tuntuvat kuitenkin toimivan täydellisesti Protonilla ilman explicit synciä, joten ongelma taitaa koskea "vain" xwayland softia.

Intel kannettavalla drm_info näyttää raportoivan explicit sync tuen olevan jo kernel ajuritasolla päällä (SYNCOBJ_TIMELINE), eli kwin ja mesa on nähtävästi molemmat backportattu Wayland explicit syncille, jos käytössä on Intel/AMD.

Screenshot_20240516_214804.png
 
Viimeksi muokattu:
Olen käyttänyt vuosia opensusea ja päivittänyt harvoin. Oiskohan tuo Fedora sitten seuraava, kun opensusea ollaan muuttamassa. Vai muuttuuko vaan paremmaksi. Paketinhallinta on tässä aivan hirveän hidas ssd levylläkin.
 
Olen käyttänyt vuosia opensusea ja päivittänyt harvoin. Oiskohan tuo Fedora sitten seuraava, kun opensusea ollaan muuttamassa. Vai muuttuuko vaan paremmaksi. Paketinhallinta on tässä aivan hirveän hidas ssd levylläkin.
Mitäs muutoksia Opensuseen on tulossa?
 
Taisin tuolla distroketjussa aiemmin itkeä, kuinka rasittavaa on joutua syöttämään salasana tyypillisesti 5 kertaa, jos LUKS on käytössä. Kannettavan kun avaa aamulla ensimmäistä kertaa, niin tyypillisesti rutiini oli: LUKS salasana -> login salasana -> OS päivitykset/reboot -> LUKS salasana 2x -> login salasana -> kannettava käyttövalmis.

Tänään laitoin Fedoran käyttislevyn kryptauksen aukeamaan TPM:llä ja sormenjäljellä käyttikseen kirjautuminen. Tuossa ohjeet jos joku muu haluaa tehdä saman, toimi ainakin SDDM/KDE Plasma 6 Fedorassa, secure boot päällä TPM varten:

LUKS avaus TPM piirillä:

Sormenjäljellä käyttikseen kirjautuminen:
 
Jos joku muukin kuin minä on ihmetellyt miksi fontit jotkin näyttää linuxissa hieman suttuiselta ja "boldatulta" verrattuna windowsiin (esim. reddit firefoxissa), niin tässä mahdollinen ratkaisu.

Nykydistrot käyttää freetypen truetype-interpreterin versiota 40, mikä käyttää vähemmän hintingiä kuin versio 35. Näyttää paremmalta hidpi-näytöllä, koska fonttien muotoa ei murjota pixel gridiin, mutta suttuiselta jos resoluutio on matala, kuten 15.6" fullhd-läppärillä. Lisäksi hinting on yleensä asennossa "slight", vaikka pitäisi olla "full", siis jos haluaa fonteista mahdollisimman terävät.

Ainakin fedora 39:ssä toimii tämä

~/.bashrc fileen rivi export FREETYPE_PROPERTIES="truetype:interpreter-version=35"

/etc/fonts/conf.d hakemistosta pitää poistaa symlink /usr/share/fontconfig/conf.avail/10-hinting-slight.conf ja laittaa tilalle symlink fileen /usr/share/10-hinting-full.conf fileen

Lisäksi fedoran sisältämät liberation fontit on liian uusia toimiakseen vanhemmalla freetypellä (mintin ei ole), joten pitää lisäksi asentaa versio 1.05.3 vaikka täältä: fontit

Siirsin /usr/share/fonts:ta kaikki liberation-alkuiset fontit muualle talteen, asensin nuo paketin fontit /usr/share/fonts juureen ja ajoin fc-cache --force. Relogin ja fontit näyttää ainakin minun mielestä paremmalta, siis ne mitkä tuolla v35:lla toimii kunnolla.

Em. liittyen hokasin äsken, että jos haluaa käyttää vanhempaa fonttiengineä niin sitähän on käytetty vanhoissa distroissa oletuksena, eli sopivat fontitkin löytyy sieltä. Kopioinkin omaan fedora 40 läppäriini /usr/share/fonts sisällön fedora 25:n asennuspaketista. Taidan ottaa käyttöön myös pöytäkoneessa, koska windowsmaiset ohuet fontit miellettää omaa silmääni enemmän myös 24" 4k-näytöllä.
 
Viimeksi muokattu:
Poltin pari viikkoa sitten Ubuntun virallisen iso-imagen USB-tikulle ja formatoin jäljelle jäävän tyhjän tilan siten, että samaa tikkua voi käyttää myös tiedostojen siirtelyyn. Käytin tikkua ainakin kolmessa eri koneessa, ja kaikissa tapauksissa boottaus sujui ilman ongelmia ja tiedostotkin näkyi hyvin.

Nyt jostain syystä en pysty enää tekemään tuota samaa, vaikka käytän täsmälleen samaa 32 gigan USB-tikkua ja iso-imagea. Jos teen tikun boottaavaksi, niin mikään osiointityökalu ei näe sitä vapaata tilaa siellä, eli en pysty luomaan sitä tiedosto-osiota.

Valitettavasti en enää muista tarkalleen, mitä tein silloin kun sain tiedosto-osion tehtyä. Mielestäni en tehnyt mitään komentorivikikkoja tai muutakaan erikoista, vaan käytin KDE:n Startup Disk Creatoria ja Partition Manageria eli samoja työkaluja joita nytkin yritän käyttää. Miten on mahdolista, että ne ei enää toimi vaikka vielä pari viikkoa sitten toimi? :confused:
 
Pelikansa ylistelee Lutrisia mutta jostain syystä itsellä on aika köyhät tulokset pelien saamisesta toimiman sillä. Winellä saanut paremmin toimimaan mutta Lutrisissa ei vaan lähde vaikka mitä asetuksia säätäisin. Liekö sitten niin vulkaniin nojaava mitä läppäri ei täysin tue, kun peliä skriptistä asentaessakin tulee terminaaliluukussa jatkuvaa valitusta miten vulkan-tuki on puutteellinen?
 
Eikös Vulkanin saa pois asetuksista? Täällä Lutris kyllä toiminut ok, mutta pelit tuntuu silti Steamin kautta lisättynä pyörivän hieman paremmin.
Screenshot_20240520_124900.png
 
Eikös Vulkanin saa pois asetuksista? Täällä Lutris kyllä toiminut ok, mutta pelit tuntuu silti Steamin kautta lisättynä pyörivän hieman paremmin.

Olen kaikkea yrittänyt säätää ja näin maalaisjärjellä ajateltuna yhteensopivuudenhan pitäisi olla Winen kanssa vastaavalla tasolla vähintään kun kerran samoja kirjastoja käyttää, mutta en tiedä mikä sitten tökkii. Olen sen DXVK/VKD3D:n laittanut pois päältä eli kaiketi vulkanin pitäisi silloin olla disabloituna täysin. Luultavasti joku yksi pikku juttu mitä ei nyt vaan huomaa. Mutta tokkopa ne pelit sen nopeammin ainakaan Lutrisilla pyörisivätkään ilman vulkaneita.
 
Moi, millä koodinpätkällä sitä saikaan linuxissa (ubuntu) wi-fin pysymään päällä, vaikka sen vahingossa sulkee? Tahtoo olla vanhuksilla tapana se saada kiinni ja sitten kone onkin rikki jne. Kiitos. Siis wi-fi täytyy käydä taas käsin laittamassa päälle. Muuten kyllä yhdistää normaalisti.

Automaattinen yhdistäminen päälle ja Wifi-ikoni pois paneelista niin eivät pääse ronkkimaan sitä.
 
Nvidiasta puheenollen pitäisikö videoiden rautaenkoodauksen (nvenc, ilmeisesti wrapperilla myös vaapi..?) toimia nvidialla ihan heittämällä? Itse en saanut viimeksi kokeillessani toimimaan kuin dekoodauksen, joten pöytäkoneen työpöydän striimausta läppärille ei voinut käyttää.

Btw. jos joku on joskus yrittänyt ajaa jotain ohjelmaa automaattisesti roottina, niin systemd skriptillä onnistuu ainakin helposti. Esimerkkinä itse käynnistän sellaisella evdoublebindin, jolla mappaan nuolinäppäimet shifteihin ja kontrolleihin ja escapen molempiin altteihin, eli vastaava kuin xcape mutta toimii myös waylandilla.

/etc/systemd/system/double-bind.service:

[Unit]
Description=double bind modifiers

[Service]
ExecStart=evdoublebind /dev/input/by-id/usb-Lite-On_Technology_Corp._ThinkPad_USB_Keyboard_with_TrackPoint-event-kbd 125:108,127:103,56:1,100:1,42:105,54:106
Restart=Always
PIDFile=/tmp/double_bind_pid

[Install]
WantedBy=multi-user.target

systemctl enable double-bind
 
Viimeksi muokattu:
Pelikansa ylistelee Lutrisia mutta jostain syystä itsellä on aika köyhät tulokset pelien saamisesta toimiman sillä. Winellä saanut paremmin toimimaan mutta Lutrisissa ei vaan lähde vaikka mitä asetuksia säätäisin. Liekö sitten niin vulkaniin nojaava mitä läppäri ei täysin tue, kun peliä skriptistä asentaessakin tulee terminaaliluukussa jatkuvaa valitusta miten vulkan-tuki on puutteellinen?
Vähän heikkoa oli oman läppärin 5600h:n ja vanhan pöytäkoneen r9 290:n kanssakin. Ei niin ei. Lutris tosin kaatui jo monta kertaa joitain pelejä asentaessakin. Jos pelata haluaa, niin ei ole Windowsin voittanutta.
 
Jos pelata haluaa, niin ei ole Windowsin voittanutta.

Heh, luulin etten tarvitse gpu passthroughia mihinkään kun sen kohtalaisen suurella vaivalla virittelin toimimaan, mutta yllättäen HROT ei suostu toimimaan protonilla pelattavasti, vaikka useimmat AAA-pelit ilmeisesti jo toimii.
 
Heh, luulin etten tarvitse gpu passthroughia mihinkään kun sen kohtalaisen suurella vaivalla virittelin toimimaan, mutta yllättäen HROT ei suostu toimimaan protonilla pelattavasti, vaikka useimmat AAA-pelit ilmeisesti jo toimii.
Kyllä se yhteensopivuus varmaan koko ajan paranee. Sitä odotelllessa. Tosin ei tuo dualboottikaan ihan kamala asia ole. Hyviä asioita molemmissa järjestelmissä.
 
Mikähän bluetooth usb-dongle toimisi luotettavasti linuxissa? HP:n pöytäkoneella ja fedoralla on lähes mahdotonta saada bluetooth-kuulokkeet yhdistettyä. Jos kuulokkeet pitää aina samassa koneessa kiinni eikä koskaan yhdistä niitä muualle, niin toimii kohtalaisesti. Muussa tapauksessa pitää aina parittaa uudelleen ja se on yhtä helvettiä, koska laitetta joko ei löydy, tai sitten fedora yhdistää laitteen minkä paritus on jo moneen kertaan purettu (!?!?). Ainoa tapa mikä toimii jotenkin, on ajaa bluetooth-palvelu alas, laittaa kuulokkeet paritustilaan, käynnistää bluetooth-palvelu ja yrittää sitten paritusta. Asiaa ei helpota se, että kuulokkeiden saaminen paritustilaan onnistuu ehkä yhdellä kertaa viidestä, mutta ei kai uutena lähemmäs 300 euroa maksaneilta sonyn kuulokkeilta voi mahdottomia vaatiakaan :p

En ole kylläkään varma onko vika bluetooth-piirissä vai eikö bluetooth vaan toimi linuxissa tuon paremmin. Äsken piti katsella 20min rust-video loppuun, mutta se 20min meni kuulokkeiden paritukseen.

Tämä ongelma on ilmeisesti ratkennut itsestään jonkin päivityksen yhteydessä, nyt kuulokkeet yhdistyy automaattisesti eikä haittaa vaikka niitä välillä käyttää puhelimella. Tai sitten ne ei jostain syystä toiminut xorgilla mutta toimii waylandilla.
 
Kyllä se yhteensopivuus varmaan koko ajan paranee. Sitä odotelllessa. Tosin ei tuo dualboottikaan ihan kamala asia ole. Hyviä asioita molemmissa järjestelmissä.

Joo passthroughilla toiminee kaikki mahdollinen mitä tarvitsen, joten dualboottia tuskin enää tulen tarvitsemaan. Siitä en ole koskaan pitänyt, liikaa vaivaa ja ongelmia.
 

Statistiikka

Viestiketjuista
262 367
Viestejä
4 554 257
Jäsenet
74 959
Uusin jäsen
arim

Hinta.fi

Back
Ylös Bottom