J
jantarmantar

  • Nov 21, 2017
  • Joined Oct 18, 2013
  • fjmorazan Sorry for the late reply and thanks for the suggestion. I finally got around to trying your suggestion, but unfortunately it did not help me. Although the artifacts are very minor and can be easy to miss on a casual glance but they become annoying very soon.

    From the posts I linked above, it seems the root cause (https://bugs.chromium.org/p/skia/issues/detail?id=6663) was indeed in Chromium's skia component's character shaping algorithm. This was fixed in Chromium 60, but Electron is still based on Chromium 58. So until Electron is updated and VS Code/Atom start using the updated Chromium, we are stuck with this issue.

    PS: It seems besides me, you are the other KCP user who regularly updates VS Code. Just wanted to say thank you for your efforts.

  • Thank you for making the previous version available again.

    Yes, downgrading to 2.8 indeed fixed the weird font rendering issue that affected VS Code.

    • Any KaOS users that uses VS Code from KCP affected by a bug that resembles the issue described here?
      https://github.com/Microsoft/vscode/issues/35675

      Quite a few users reported issue resolved after downgraded from FreeType 2.8.1 to FreeType 2.8.0. Unfortunately, I don't have the previous version in my cache folder anymore to verify if it indeed will resolve the issue.

      Atom users also reported a similar issue and the fix.
      https://github.com/atom/atom/issues/15737

      Any VS Code or Atom user able to confirm the issue and/or the fix?

    • It might be worth pointing out that if you just want the basic printing to work, try giving gutenprint drivers a shot. I see MX492 listed as supported printer by gutenprint. Don't be afraid of the "experimental" driver tag, I have a Canon MX870 all-in-one that works just fine, including printing and scanning over WiFi, all without needing the official Canon drivers.

    • Yes, that bug report's attachment has the exact same error messages that I posted -- and my laptop happens to be a Dell Precision (slightly different model) same as the bug report's poster.

      However, your suggestion to boot into level 3, prompted me to look at the Linux command-line in GRUB. It seems I had blacklisted some modules (microcode,radeon) way back when I had some different issues related to 4.0 kernel change. Once I removed the blacklisted modules, my laptop is now able to boot with both, linux-4.9.10 and linux-next-4.10.0. So far I haven't observed any ill effects due to no longer blacklisting the above modules. I guess at some point they became unnecessary, but didn't show any problems until the recent kernel update.

      Thanks for your help!

    • I have a Dell laptop M4800 with hybrid AMD and Intel graphics. After I upgraded to linux-4.9.10, system hangs with following message.

      [drm:amdgpu_atombios_get_connector_info_from_object_table [amdgpu]] *ERROR* invalid con_obj_id 22 for device tag 0x0002
      [drm:amdgpu_atombios_get_connector_info_from_object_table [amdgpu]] *ERROR* invalid con_obj_id 22 for device tag 0x0020

      The only thing I could do then was force a power shutdown. However, if I disabled "Switching Hybrid Graphics" in BIOS, boot process reached a stage where SDDM failed to start (cored-dump SEGV), but I at least could switch to another VT and login.

      Installing linux-next-4.10.0 didn't help either. However switching back to linux-4.8.15 made the system usable again.

      Here's output from inxi -G

      Graphics: Card-1: Intel 4th Gen Core Processor Integrated Graphics Controller
      Card-2: Advanced Micro Devices [AMD/ATI] Venus XT [Radeon HD 8870M / R9 M270X/M370X]
      Display Server: X.Org 1.19.1 driver: intel Resolution: 1920x1080@60.02hz
      GLX Renderer: Mesa DRI Intel Haswell Mobile GLX Version: 3.0 Mesa 13.0.3

      Any idea what the problem could be?

    • I thought SpiderOak being a user level service and one needing an X session will be complicated managing it with systemd. But it may not be -- I'll explore that as an alternative.

      Thanks

    • Yes, I was thinking something basic like that would work. I was trying to make my script a little smarter by checking for network availability. I came across https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ which suggests (or that's how I interpreted) if I have something like following in my KDE user level autostart script, it would work:

      #! /bin/sh
      
      echo "Checking network status" > $HOME/net.log
      
      loop_ctr=1
      while ! systemctl status network-online.target >> $HOME/net.log && [ $loop_ctr -le 10 ]; do
          echo "Sleeping for 5 seconds" >> $HOME/net.log
          sleep 5
          loop_ctr=$((loop_ctr+1))
      done
      ip addr list >> $HOME/net.log
      
      /usr/bin/SpiderOakONE

      The script didn't work the way I had hoped because network-online.target was active and yet (except for the loopback interface) I didn't have an IP address assigned. I may have misunderstood, but any clue, why network-online.target becomes active before an IP address is obtained?

      Thanks

    • I have set up SpiderOak to autostart, but it always remains disconnected -- that is, until I quit the application and restart. This must be SpiderOak specific issue because dropbox seems to be able to auto-connect after network becomes available. SpiderOak seems to have abandon their support forums and a general search yields http://www.clausconrad.com/blog/restarting-spideroak-after-switching-networks . Not 100% sure, but from SpiderOak's behavior it looks like, SpiderOak probably latches on to lo interface and waits forever to get online.

      Any ideas how I can make applications which are set to autostart wait until network (in my case wireless) is available? I guess I can write a shell-script that just sleeps for some time before starting SpiderOak, but wanted to check with others if they had faced this issue and what the solution was.

      Thanks

    • Never mind the question. The title says bi-weekly. Read the contents, missed the title 🙂

      • demm replied to this.
      • +1 for getting the new shiny thing sooner. Hopefully the experience will be like that of chrome-dev; new features sooner and rare, if any, breakage.

        I didn't quite understand as to how often you will be building from git. I am guessing anytime you detect significant changes or a bug is reported/fixed?

      • libreoffice weighs in at more than 700+ MB unpacked. I noticed that libreoffice sdk documentation (which BTW is available online) is almost half of the total size. If typical KaOS user is anything like me, s/he nowadays relies more on google or other online sources to find information than press F1 key.

        I wanted to ask, if it was feasible to cut out SDK doc out of the main package and into a separately installable package. Having asked that, I took a glance at libreoffice PKGBUILD and it looked anything but trivial, so if it becomes a maintenance nightmare, I understand.

        Thanks

        PS: Generally speaking package size isn't an issue nowadays. But, I upgraded all my computers when SSD came out a few years ago and now all of them are 120GB, down from 500+ GB. I am sure in couple of years I'll upgrade again and a few extra GB wouldn't be an issue. 🙂

      • You might want to check the manual to see if your particular model supports any version of PCL. I have a Brother printer (Model HL-2280) and I am using "Generic PCL 6" without any issues.

      • git-2.6.5 doesn't have this issue, so must be a regression in 2.7. Hopefully a fix will be released soon.

      • I noticed that git recently stopped obeying the ignore patterns from the global core.excludefiles specification file. Has anyone else noticed that too? If it is not just me then I am wondering if it's related to the recent upgrade to git 2.7.

      • I can also confirm that changing away from Breeze SDDM theme fixes the issue.

        - Thanks

      • I tried installing libgl, mesa, clang, llvm from the repo, but that hasn't helped. Unfortunately, I didn't have any older version of xf86-video-intel in my pacman cache. Also, iirc, this behavior started somewhat more recently (between 3 to 8 days ago) than the last build of intel video driver.

        Here are some other things that seemed like a pattern to me but not sure if they provide any important clues:

        • Each time there is a login failure, "journalctl -b -0" show "Auth: sddm-helper exited with 1" error message after "Auth: sddm-helper exited successfully" message. On successful logins, only "Auth: sddm-helper exited successfully" message is present, followed by the normal kdeinit messages.

        • Login failures happen only with plasma sessions, plasma-wayland login sessions have always worked so far (albeit with current wayland idiosyncrasies)

      • Just a quick me-too post. I have two laptops with Intel graphics and both have this same issue (successful login in 1 out of 5/10 attempts). I'll try what demm has suggested and see if that solves the issue.