• Content Count

  • Joined

  • Last visited

Everything posted by belfastraven

  1. Happy to help test any desktop (building pinebookpro. 5.91 dev build currently) I tried KDE with all boxes checked--unfortunately build kept failing at the very end because of failure to get gnu pg key for oibaf ppa. I'll try again without enabling whatever uses that ppa.... Is there a set of activities/checklist to try for the testing? I can build reasonably quickly and am actually using the PBP with SPI u-boot booting NVME, so I can do anything on an SD card without hurting anything....
  2. Re building different desktops: The capability to build various desktops through the build system is being worked on and tested now. From my initial look, it seems like many desktops including gnome, kde, cinnamon, lxde xfce and various others are being thought about for inclusion. I just started to try to play a bit with desktop (as opposed to master) branch of the github. Obviously, this is not released yet...
  3. Hmmm if your Ctrl-Alt-F2 prints a #, I believe it is somehow using the us (or perhaps ANSI) keyboard layout. That is what all of my other keyboards show by default--the PBP is my only ISO keyboard device. I'm certainly not an expert on any of this. If you want to build groovy, I believe you need to used EXPERT=yes on the ./ command. I have done a dev build, which builds kernel 5.9(.1 right now) . I did a console rather than a desktop build so I could play with installing a different desktop. Groovy runs very well so far for me. I am booting the NVME from SPI flash.
  4. When you speak about opening a terminal window, do you mean on the desktop? or do you mean opening a terminal console with CNTL-ALT-F(some-number). The mechanisms are different. For the CNTL-ALT-F(some-number) , if I set the /etc/default/keyboard file so that XDBMODEL="pc105" XDBLAYOUT="gb" XDBVARIANT="intl" I get the pound sign at shift-3. For the desktop console, it is controlled by whatever desktop manager you are using, I believe. So if in the desktop settings you have the pc105 UK keyboard selected, that should be working. If it works
  5. Are you trying to build a kind of "kiosk" application? XFCE is a much less resource intensive desktop than gnome and it actually has a kiosk mode-- you also have the capability of controlling the color of the desktop and what appears on a panel: see here: I am excited about the project that @Igor has mentioned; for now, I tend to build a "server" version of software and then install a desktop on the running system. I imagine that would not work for you even if you used clonezilla or a like program to copy the configured image, sinc
  6. Given the gsettings you are running, I assume you are using a GNOME desktop? if so can you try, gsettings set org.gnome.desktop.background picture-options 'none' gsettings set org.gnome.desktop.background primary-color '#000000' Assuming that since you know the user and you are using autologin ( as that won't change the background for the display manager) that will set a black background. If this is e.g. an xfce, lxde , etc. desktop, that will not work. there are other gsettings keys that you can set to eliminate de
  7. If anyone wants instructions for updating on debian/ubuntu as well as arch see: latest keyboard updater  with instructions for debian and arch.. Also, I have been running the pcm720 u-boot that @lanefu mentioned since the end of July, since it allows me to boot my nvme. I have played a bit with trying to work the patches/versions into the build system, but haven't been successful as of yet. . See here for the source There is one atf patch (which we may already have) and 4 u-boot p
  8. I can test, too. I have been running with (currently) an armbian dev build with 5.8.9 kernel on focal with a gnome desktop and pcm720's uboot on spi flash, botting an nvme. The only strangeness that I have been running across is that if I boot off of an SD card, rebooting without shutting down seems to boot the NVME. I haven't spent much time investigating, though--I was just so excited to be using armbian builds again..:-)
  9. Thanks for your response. I thought it that was so, but then, perhaps that test for it should be removed from ? Otherwise, the build system will go ahead and download the sources anyway, even though it had said previously it would not., so the user documentation doesn't match what is happening. (this is not theoretical--it happened to me--twice before I figured out what was happening--:-) ) If you are using BUILD_ALL, what would now be considered the proper way to avoid having sources downloaded?.. If everyone who builds anything is just supposed t
  10. I've noticed that in order to be able to build offline, I need not only to specify OFFLINE_WORK=yes as per this documentation: OFFLINE_WORK ( yes | no ): skip downloading and updating sources as well as time and host check. Set to “yes” and you can collect packages without accessing the internet but also IGNORE_UPDATES=yes. Probably because of this is # ignore updates help on building all images - for internal purposes if [[ $IGNORE_UPDATES != yes ]]; then display_alert "Downloading sources" "" "info" I don't see here in m
  11. @Igor, I've been playing with the Cubox builds and everything is working well. On WIndows, I am thinking about suggesting the built-in powershell tool Get-FIlehash for verification and explaining how to write the hash into a file to check it. gnupg, which installs gpg, and gpg4win, its windows graphic frontend with extra bells and whistles, work fine for authentication, and the command line use is the same as on linux. If we have any windows experts here who would like to weigh in, I'd love to here from them. Of course, if people are running WSL , they can just do th
  12. @igor, I'm very glad you finished it--I don't think anyone wants me to mess around with the build system. I am back to working on the doc. I'm trying to determine the best tool to use on windows to shasum the xz file. certutil, e.g. expects the user to compare the hashes (not very friendly, I think) , Microsoft has a tool which I haven't tried yet, but will try tonight. Also, the doc still says builds for supported desktops are bionic and buster--wasn't sure that was still true. This is where I am currently, if anyone wants to look: https://githu
  13. @Igor (and anyone else who wants to weigh in on the changes for xz compression) Could you take a look here at the section toward which you pointed me. This now will do compression first and then the shasum and gpg stuff. The shasum stuff is working (I tried it twice :-) ) I left "the "yes" option and the "no compression" options the way they were. I wasn't sure what everyone wanted --whether we should now use xz,sha,gpg by default, or what. I was not able to properly test the asc file generation bec
  14. @Igor one last issue. When I downloaded the odroid 4c files ,(The .img.xz, .asc and .sha for bionic current desktop) I realized that no program that i can find will verify/validate the download or authenticity of the xz when the sha or asc generation is run against the uncompressed image , which seems to have been the case. Is it possible to generate the sha and asc file using the .img.xz files? If not, is it the intention the users should uncompress the xz files before running the checks? They obviously don't need to do that to write the file with Etcher or USBImager.
  15. Okay, thanks Igor, I am working on it and I did sign up for the Alsassian project management stuff.
  16. OK sorry--brain obviously not working. So am I understanding correctly that three files will need to be downloaded, the .img.xz, the .asc. and the .sha and that the new way of checking authentity and validating are gpg --verify "some-name".img.asc sha256sum --check "some-name".img.sha ? Also, the page I saw only mentioned etcher and not USBImager. SHould it also mention USBImager? Could someone point me to a download that has everything in place for the new system: I'd like to test what I am writing. I normally build things and when I tr
  17. Igor, re your first request, I looked at the linked page, but didn't see anywhere there anything that indicates that the compressed file would be 7z. It says to use 7-zip or p7zip to uncompress the file, which should also work for xz files. Did you want to indicate that the compressed files would be .xz? Do you have a preference that a different tool be used?
  18. @chwe I think armbian firmware needs to have rockchip/dptx.bin which is in the linux-firmware-git now. That would get rid of a few dmesg messages. It is necessary for dp over USB c, I believe. Also, I note these entry from the Xorg.0.log re touchpad: (there are others like these): bodling is mine 12.222] (II) event4 - HAILUCK CO.,LTD USB KEYBOARD Touchpad: is tagged by udev as: Touchscreen. and 112.184] (II) config/udev: Adding input device HAILUCK CO.,LTD USB KEYBOARD Touchpad (/dev/input/event4) [ 112.184] (**) HA
  19. Great! If you put the brightness to maximum before trying to run this, you shouldn't have a problem. People have been noting the initial dimness on the Manjaro arm forums and in the Pine64 forum. Note that it comes up with US keyboard. If you have an ISO keyboard, you may want to change the mapping. Although in the Manjaro build, one sees all of the Hailuck keyboard definitions twice (in dmesg). but the touchpad does work.... Here we see them 4 times. I am looking to see if I can figure out what is actually controlling them. I've seen in the past
  20. I noticed two other recent Rockchip drm changes in Patchwork 1-1-drm-rockchip-fix-integer-type-used-for-storing-dp-data-rate-and-lane-count 37-51-drm-rockchip-Drop-explicit-drm_mode_config_cleanup-call but have not had a chance to see if either or both of those enabled booting without using the manjaro kernel, but with the patches already identified. The first is another tsys patch. At least we no longer have to disable sound to use the serial console:-) I'm going to try building with the v5.6 branch this weekend....
  21. Ok. Thanks, will do. I keep checking mainline for the dts etc, too. There have been several changes in the manjaro repo , also, re suspense (S3) , etc, in the last couple of days. I hope by 5.7 things will have settled a bit!. I've been running with mainline u-boot and kernel and gnome on Wayland, and it really is a nice device. I am more e comfortable in the Debian world, though, so will be happy to get a mainline armbian build going... We also need the dts(s) in u-boot,as well.....
  22. Oh sorry--I still didn't see force-hpd in the eDp panel defs there. If you look at the closed issues on the Schramm kenel, there was an indication that that had fixed the display problem for users who were not getting the display (I was one of those). I don't see that line in the current 5.5 dts, but If you are still building with 5.4.y, perhaps it is still necessary. I am sure I am dating myself here, but I feel as if I am playing "Adventure" : "YOU ARE IN A MAZE OF TWISTY LITTLE PASSAGES, ALL ALIKE" I'm not very good with the current build system. Are you
  23. Check out the attached screenshots of commits. I believe you may need all three of these patches. One is modifying the simple panel driver to include our specific panel, one changes timing , one is to force recognition of the panel, I believe. I sent the screenshots becuase I couldn't figure out how to get the patches off of gitlab, but I imagine you will know how to do that. There have been many patches over the past 3 months, but I think these are the ones that enabled the display. There are more for bluetooth, wifi, sound, usb-c , etc. WE now have a mainline u-boot
  24. @chwe, Try this (on manjaro pinebook-pro dts) to get sound and uart: I think I got it from mrfixit2001, if not it was ayufan.... This now works for me-- just giving "patch" form so you can see where the changes are.... -- 5.5.rk3399-pinebook-pro.dts 2020-02-05 11:06:24.354098350 -0500 +++ my.v5.5-rc7-panfrost-fixes.rk3399-pinebook-pro.dts 2020-02-05 10:58:51.545953609 - @@ -197,10 +197,12 @@ simple-audio-card,cpu { sound-dai = <&i2s1>; + system-clock-frequency = <12288000>; };
  25. @chwe--I just found this in @ayufan's repository:" " stdout-path = "serial2:1500000n8"; // disable stdout-path as it causes instability due // to sound card power leak //stdout-path = "serial2:1500000n8"; " The Manjaro boot args don't include stdout-path, or earlycon=uart8250 but do include console=ttys2. Maybe if I get brave, after dinner I will try removing that from the boot arguments.... The current Manjaro boot.txt doesn't sho