1. Fórum Root.cz
  2. Profil Ladislav Nešněra
  3. Zobrazit příspěvky
  4. Příspěvky

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Ladislav Nešněra

Stran: [1] 2
1
Software / Přesun map do TomTom s rsync a skryté soubory
« kdy: 25. 06. 2023, 16:54:36 »
Slibovaná "doživotní" aktualizace TomTom navigace se zvrhla v předpokládané  :-\ Tak jsem chtěl vyzkoušet, zda funguje prachsprosté překopírování. Jenže 300 MB souboru se do stařičké navigace moc nechtělo, tak jsem sáhl po rsync a laboroval, a laboroval, .. až mi to začalo hlásit, že došlo místo:  :o
  • i s du -sch .[!.]* * | sort -h nenacházím, kde/čím se to zaplnilo - soubory by měly zabrat sotva 1/3 kapacity
  • podezírám rsync (spoužívám -P), že ty mnohé neúspěšné pokusy zůstaly někde ležet (dokonce mě napadlo, jestli v sobě navigace rsync přímo nemá, podobně jako je to potřeba pro synchronizaci mezi linuxovými stroji přes ssh, ale to asi obstará rsync jen z mé strany do vystaveného úložiště navigace). Zpětně si myslím, že jsem rsync často ukončoval pomocí Ctrl+C předčasně - nebyl zamrzlý, jen dlouho trvala kontrola integrity (i htop hlásil proces jako mrtvý)
  • původní mapa by se s novou nevešla, tak jsem ji dal pryč. To je průšvih, protože "systém" pro rozběh alespoň jednu vyžaduje, čímž jsem si odřízl cestu k resetu do továrního nastavení (rozborka HW ukázala, že to žádný další skrytý trik/rozhraní/paměťovou kartu nemá)
Nějaký nápad, jak z toho ven?  ::)

2
Software / Re:Nenažraný Firefox - jak zjistit, kde je ta černá díra?
« kdy: 25. 06. 2023, 15:33:32 »
@Jan Fikar: Rozšíření jsem používal a pak přestal, nebo nějak "vypadlo"  :)  Zkusím znovu i s tím slušným seznamem výjimek  ::)

(Tohle vypadá na dlouhý hon - jako u temné/skryté hmoty/energie  ;D)

3
Software / Re:Nenažraný Firefox - jak zjistit, kde je ta černá díra?
« kdy: 21. 06. 2023, 10:48:43 »
Předně, díky za všechny reakce  :)
  • ano, starší stroj, více oken a hromada tabů. Nemám problém s tím, že to "něco" žere, ale se zjevným rozporem mezi about:performance hlásícím minimální zátěž a reálným vytížením CPU. Ta vysoká zátěž není vždy, proto předpokládám, že to dělá nějaký web
  • @alex6bbc: jiné prohlížeče se samozřejmě chovají jinak. Vzhledem k předchozímu, "stejnou" situaci nenavodím ani na FF. Mám tutéž zkušenost jako @kanoe22 - často pomůže minimalizace (překvapivě výrazně) nebo uspání počítače, ale někdy to žere a žere. (Všiml jsem si třeba, že Chromium je výrazně šetrnější při přehrávání videí na YT.) Těžba mě též napadla (obzvlášť když vlezu na Facebook  ;D), ale pořád stejný problém - nedokážu zjistit, který tab za to může  :(
  • @Karel Karlik: about:memory vyzkouším, jen to chvilku potrvá

4
Software / Nenažraný Firefox - jak zjistit, kde je ta černá díra?
« kdy: 17. 06. 2023, 00:57:15 »
Podle htop je Firefox nejnenažranější aplikací, která konzumuje běžně (byť mám třeba všechna okna minimalizovaná) přes 100% CPU. Tomuto výpisu věřím, protože koreluje s teplotou CPU případně zabitím procesu. Zkoušel jsem trik s about:performance, ale ten se tváří, že vše je cajk a žádný Tab nepřekračuje úroveň "Low". Nějaký nápad, jak viníka dopadnout?

5
Sítě / Re:Ping přes konkrétní rozhraní vs. nastavení směrování
« kdy: 26. 10. 2021, 17:02:23 »
Situace je taková, že mám noťas s NixOS, zaujalo mě hlavně deklarativní nastavení, leč explicitně zmíněný firewall jsem přehlédl. Vlastně jsem na firewall resp. nastavování sítě na Linuxu více narazil až nyní díky laborování s USB tetheringem na PinePhone (čti kapesní linuxová adventura   ;D ) a tedy potřebou kontrolovat, které zařízení připojení obstarává.

Kód: [Vybrat]
# iptables --line-numbers -nvL -t nat
Chain PREROUTING (policy ACCEPT 39798 packets, 3216K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 6 packets, 540 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 147K packets, 12M bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 147K packets, 12M bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1     147K   12M LIBVIRT_PRT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_PRT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        1    40 RETURN     all  --  *      *       192.168.122.0/24     224.0.0.0/24       
2        0     0 RETURN     all  --  *      *       192.168.122.0/24     255.255.255.255     
3        0     0 MASQUERADE  tcp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
4       53  3965 MASQUERADE  udp  --  *      *       192.168.122.0/24    !192.168.122.0/24     masq ports: 1024-65535
5        2   168 MASQUERADE  all  --  *      *       192.168.122.0/24    !192.168.122.0/24
Těch rozhraní je na noťasu víc (např. od libvirt nebo interní 3G modul), tak raději celé, ať nematu
Kód: [Vybrat]
$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp0s25: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 3c:97:0e:51:30:b7 brd ff:ff:ff:ff:ff:ff
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 60:67:20:d8:bc:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 78851sec preferred_lft 68051sec
5: virbr0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:0b:ed:2b brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
251: wwp0s20u4i6: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether 76:77:56:98:4c:7b brd ff:ff:ff:ff:ff:ff
253: enp0s26u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether f6:80:23:7e:37:6f brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.78/24 brd 10.42.0.255 scope global dynamic noprefixroute enp0s26u1u2
       valid_lft 3279sec preferred_lft 3279sec
    inet6 fe80::a1a9:83a0:b0ae:dd2e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
Skutečně mám net.ipv4.conf.enp0s26u1u2.rp_filter = 2, ale nezdá se, že by se "zapnutí" logování nějak projevilo na výpisu (# dmesg -WH). Zkusil jsem i to watch (díky, úplně jsem zapomněl, že existuje) s iptables, ale vrací jen nuly.

6
Sítě / Re:Ping přes konkrétní rozhraní vs. nastavení směrování
« kdy: 25. 10. 2021, 22:19:34 »
@FJ: Skvělý odhad 8) NixOS má firewall jako výchozí nastavení (dobré vědět  :) ). Po vypnutí pomoci systemctl stop firewall ping (interval 3 s) prošel, na rozhraní ze strany noťasu se návratové pakety objevovaly celou dobu
Kód: [Vybrat]
tcpdump -i enp0s26u1u2 -n host 8.8.8.8
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s26u1u2, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:01:31.570551 IP 10.42.0.78 > 8.8.8.8: ICMP echo request, id 128, seq 146, length 64
22:01:31.634330 IP 8.8.8.8 > 10.42.0.78: ICMP echo reply, id 128, seq 146, length 64
22:01:34.578521 IP 10.42.0.78 > 8.8.8.8: ICMP echo request, id 128, seq 147, length 64
22:01:34.627137 IP 8.8.8.8 > 10.42.0.78: ICMP echo reply, id 128, seq 147, length 64
Tedy mise splněna = vím, čím testovat, co mě oprávněně mátlo a jak se toho zbavit. Díky!

Ale rád bych věc pochopil až do konce. Nerozumím tomu, jak dojde ke "schování" návratových paketů před ping/curl/..). Nastavení je:
Kód: [Vybrat]
iptables -nvL --line-numbers
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      11M   14G LIBVIRT_INP  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2     2386  640K nixos-fw   all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LIBVIRT_FWX  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
2        0     0 LIBVIRT_FWI  all  --  *      *       0.0.0.0/0            0.0.0.0/0           
3        0     0 LIBVIRT_FWO  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 2582 packets, 405K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1    6303K  498M LIBVIRT_OUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_FWI (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  *      virbr0  0.0.0.0/0            192.168.122.0/24     ctstate RELATED,ESTABLISHED
2        0     0 REJECT     all  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWO (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  virbr0 *       192.168.122.0/24     0.0.0.0/0           
2        0     0 REJECT     all  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

Chain LIBVIRT_FWX (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     all  --  virbr0 virbr0  0.0.0.0/0            0.0.0.0/0           

Chain LIBVIRT_INP (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
2        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
3        0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
4        0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

Chain LIBVIRT_OUT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:53
2        0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:53
3        0     0 ACCEPT     udp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            udp dpt:68
4        0     0 ACCEPT     tcp  --  *      virbr0  0.0.0.0/0            0.0.0.0/0            tcp dpt:68

Chain nixos-fw (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1      414  221K nixos-fw-accept  all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2     1947  416K nixos-fw-accept  all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
3        0     0 nixos-fw-accept  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
4        0     0 nixos-fw-accept  icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmptype 8
5       25  3112 nixos-fw-log-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-accept (4 references)
num   pkts bytes target     prot opt in     out     source               destination         
1     2361  637K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-log-refuse (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 LOG        tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 LOG flags 0 level 6 prefix "refused connection: "
2       24  3072 nixos-fw-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0            PKTTYPE != unicast
3        1    40 nixos-fw-refuse  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain nixos-fw-refuse (2 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       25  3112 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

7
Sítě / Re:ping přes konkrétní rozhraní vs. nastavení směrování
« kdy: 24. 10. 2021, 23:28:59 »
(upřesňuji - jde o noťas. Pro pobavení - honil jsem díky tomu duchy na PinePhone úplně zbytečně ::) a hlavně dlouho  ;D)

8
Sítě / Ping přes konkrétní rozhraní vs. nastavení směrování
« kdy: 24. 10. 2021, 22:57:43 »
Mám dvě rozhraní umožňující připojení k Internetu wlp3s0 (WiFi) a enp0s26u1u2 (USB tethering). Směrování a IP jsou nastaveny takto:
Kód: [Vybrat]
$ ip r
default via 10.0.0.138 dev wlp3s0 proto dhcp src 10.0.0.8 metric 303
default via 10.42.0.1 dev enp0s26u1u2 proto dhcp metric 1000
10.0.0.0/24 dev wlp3s0 proto dhcp scope link src 10.0.0.8 metric 303
10.42.0.0/24 dev enp0s26u1u2 proto kernel scope link src 10.42.0.78 metric 1000

$ ip a
..
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 60:67:20:d8:bc:a4 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.8/24 brd 10.0.0.255 scope global dynamic noprefixroute wlp3s0
       valid_lft 85786sec preferred_lft 74986sec
..
211: enp0s26u1u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether f6:80:23:7e:37:6f brd ff:ff:ff:ff:ff:ff
    inet 10.42.0.78/24 brd 10.42.0.255 scope global dynamic noprefixroute enp0s26u1u2
       valid_lft 2797sec preferred_lft 2797sec
    inet6 fe80::a1a9:83a0:b0ae:dd2e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
Čekal bych, že
Kód: [Vybrat]
$ ping -I enp0s26u1u2 8.8.8.8 nebo
Kód: [Vybrat]
$ curl --interface enp0s26u1u2 osel.cz projdou bez ohledu na prioritu (matric), když routa existuje, ale neděje se tak. Je to korektní chování? A pokud ano, nějaký trik na otestování průchodnosti, aniž bych musel do stavu sítě jakkoliv zasahovat?

9
Hardware / Re:Jak na přemapování kláves u kombinace GNOME Shell a Wayland?
« kdy: 01. 06. 2020, 00:41:43 »
Díky. Vyzkoušeno a funguje dobře.
Zaznamenáno, korekce a doplnění vítány.

10
Hardware / Re:Rozliší xev HW/SW chybu u klávesnice?
« kdy: 01. 06. 2020, 00:39:55 »
Díky. Vyzkoušeno, žel klávesy mrtvé i tak.
Zaznamenáno, korekce a doplnění vítáno.

11
Hardware / Jak na přemapování kláves u kombinace GNOME Shell a Wayland?
« kdy: 29. 05. 2020, 10:33:38 »
Na notebooku, kde je GNOME Shell a Wayland bych potřeboval přemapovat klávesu "Menu" na "Alt GR" a "Insert" na "Delete" (důvod viz. související dotaz). Pod X-kama to vypadá na jednoduché užití xmodmap, žel wiki Archu jsem zreprodukovat nedokázal (jako by všechny návody končily u X-ek a ještě se do toho vměšoval GNOME Shell  :-\)
Nasměrujete mě někdo?

12
Hardware / Rozliší xev HW/SW chybu u klávesnice?
« kdy: 29. 05. 2020, 08:34:40 »
Na klávesnici, jejíž historii neznám, nefunguje několik tlačítek (Alt GR | Delete | vypnutí zvuku | F12 | uspání | klávesa před Backspace). Při zmáčknutí v xevu negenerují vůbec nic. Mohu to jednoznačně považovat za HW chybu, nebo je pořád ve hře varianta chyby ovladače? (V KDE jsem beze změny vyzkoušel přepínat na všechny od HP + generické.)

13
Desktop / Re:TV přes HDMI. Na KDE bez problémů, Gnome - těžce vzdoruje
« kdy: 16. 10. 2019, 19:06:51 »
Díky za reakce  :)
Nakonec jsem to obešel úkrokem stranou - použil jsem Wayland. Tam vše, k mému velkému překvapení, naprosto bez problém :o

14
Desktop / TV přes HDMI. Na KDE bez problémů, Gnome - těžce vzdoruje
« kdy: 28. 09. 2019, 17:06:09 »
V KDE (sddm) připojuji TV bez problémů jak v jejich klikátku (příloha), tak pomocí:
Kód: [Vybrat]
$ xrandr --fb 1366x1536 --output LVDS-1 --primary --auto --mode 1366x768 --output HDMI-1 --auto --mode 1024x768 --rate 60.00 --above LVDS-1V GNOME Shell 3.30.2 (gdm) dokáži pomocí xrandr maximálně mít buď zapnutý interní display nebo jen TV. Journald reaguje na xrandr výpisem, kterému moc nerozumím (klikátko bude jen jeho GUI, neboť má výpis identický):
Kód: [Vybrat]
zář 28 15:42:18 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Allocate new frame buffer 1366x1536 stride
zář 28 15:42:18 nix11 kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun
zář 28 15:42:18 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): EDID vendor "LGD", prod id 685
zář 28 15:42:18 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Printing DDC gathered Modelines:
zář 28 15:42:18 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Modeline "1366x768"x0.0   69.30  1366 1398 1430 1486  768 770 774 782 -hsync -vsync (46.6 kHz eP)
zář 28 15:42:18 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (--) modeset(0): HDMI max TMDS frequency 190000KHz
zář 28 15:42:19 nix11 .gnome-shell-wr[1246]: Failed to use linear monitor configuration: No available CRTC for monitor 'unknown unknown' not found
zář 28 15:42:19 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Allocate new frame buffer 1366x768 stride
zář 28 15:42:20 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): EDID vendor "LGD", prod id 685
zář 28 15:42:20 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Printing DDC gathered Modelines:
zář 28 15:42:20 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Modeline "1366x768"x0.0   69.30  1366 1398 1430 1486  768 770 774 782 -hsync -vsync (46.6 kHz eP)
zář 28 15:42:20 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (--) modeset(0): HDMI max TMDS frequency 190000KHz
zář 28 15:42:23 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): EDID vendor "LGD", prod id 685
zář 28 15:42:23 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Printing DDC gathered Modelines:
zář 28 15:42:23 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (II) modeset(0): Modeline "1366x768"x0.0   69.30  1366 1398 1430 1486  768 770 774 782 -hsync -vsync (46.6 kHz eP)
zář 28 15:42:23 nix11 /nix/store/lkwjgsw0mls8c3ngp6fxcjniiqj5m9wf-gdm-3.30.3/libexec/gdm-x-session[1160]: (--) modeset(0): HDMI max TMDS frequency 190000KHz

Řádek s "kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]]" jsem pod KDE zahlédl též, ale objevil se jen jednou. Pod Gnome při každém volání prvního příkazu. Výpis pod KDE je výrazně jiný:
Kód: [Vybrat]
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper: RRNotify_CrtcChange
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         CRTC:  64
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Mode:  0
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Rotation:  "Rotate_0"
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Geometry:  0 0 0 0
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper: RRNotify_OutputChange
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Output:  67
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         CRTC:  0
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Mode:  0
zář 28 16:17:22 nix11 org.kde.KScreen[878]: kscreen.xcb.helper:         Rotation:  "Rotate_0"Nějaké doporučení? (kromě opuštění Gnome?  ;D)

15
Hardware / Re:Zyxel VMG1312-B30B - mrtvý(?) po aktualizaci firmware
« kdy: 28. 09. 2019, 14:39:50 »
Díky moc. Uvidím, jak se s tím popasuji.

(rozdíl mezi A a B jsem pochopil tak, že ani Zyxel je nerozlišuje. Rozhodně v seznamu svých produktů B neuvádí a v balíčku aktualizace obsažené PDF explicitně uvádí "VMG1312-B30A/ B30B")

Každopádně podle Lukáše to je pěkný šmejd..

Stran: [1] 2