zador.blood.stained Posted May 29, 2017 Share Posted May 29, 2017 Regarding suspend/resume and battery issues on legacy, I would prefer to have ARISC firmware sources and toolchain, otherwise I'm not sure how much can be fixed and improved Link to comment Share on other sites More sharing options...
tkaiser Posted May 29, 2017 Author Share Posted May 29, 2017 51 minutes ago, zador.blood.stained said: now we need to make images and place them in /boot directory Well, creating/making such images isn't the hard part but how to deal with 'installation'? Adding a cp call to family_tweaks function or should we add the logos to board support package (same with the various 'Pinebook only' services/settings)? Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 29, 2017 Share Posted May 29, 2017 3 hours ago, tkaiser said: Adding a cp call to family_tweaks function or should we add the logos to board support package (same with the various 'Pinebook only' services/settings)? Everything that may need updates should go to the board support package, but battery images and boot logo can be installed in family_tweaks So we need 4 files: /boot/bat/low_pwr.bmp /boot/bat/bempty.bmp /boot/bat/battery_charge.bmp bootlogo.bmp 1 Link to comment Share on other sites More sharing options...
tkaiser Posted May 29, 2017 Author Share Posted May 29, 2017 28 minutes ago, zador.blood.stained said: So we need 4 files: /boot/bat/low_pwr.bmp /boot/bat/bempty.bmp /boot/bat/battery_charge.bmp bootlogo.bmp For the 3 battery logos I would strongly recommend using those from here so users don't get confused about different charging 'behaviour' based on OS image running. Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large. Now I think we should use official wallpaper instead: (added some noise to compensate for TN panel crappiness) Link to comment Share on other sites More sharing options...
pfeerick Posted May 30, 2017 Share Posted May 30, 2017 8 hours ago, tkaiser said: Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large. Yeah, I was going to say when I saw the list of four images needed why not just re-use the battery ones that are already in use... I also prefer the blue pinecone armbian logo... looks very slick. When you say too big... are you meaning file size? 3MB being too big for the time that you see the logo? Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 30, 2017 Share Posted May 30, 2017 18 hours ago, tkaiser said: Wrt our boot logo my favourite was bootlogo-armbian_blue_1365_767.png from http://kaiser-edv.de/tmp/NumpU5/ but in the meantime I think it's too large. What do you mean by "too large"? File size? Default is 3MB, if saved to 256 colors it's 1MB without noticeable quality losses. I would prefer to use this as a boot logo too. 1 Link to comment Share on other sites More sharing options...
tkaiser Posted May 30, 2017 Author Share Posted May 30, 2017 29 minutes ago, zador.blood.stained said: What do you mean by "too large"? Just the optical size (I've not touched Pinebook for a week and when booting it again I had the chance to look at it from an 'average user' perspective). Feel free to replace bootlogo with it. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 30, 2017 Share Posted May 30, 2017 Just now, tkaiser said: Feel free to replace bootlogo with it. OK, but it will be low priority for now since we have screen tearing issues (should be fixed by modifying the DTs according to the Pine64 IRC logs) and I have shutdown/reboot issues and no logo at all on Armbian builds (so will have to make a serial console adapter to see what's going on) 2 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 30, 2017 Share Posted May 30, 2017 Quick update: no support bmp picture without bpix 24 or 32 1 Link to comment Share on other sites More sharing options...
Xalius Posted May 30, 2017 Share Posted May 30, 2017 On 5/29/2017 at 1:01 PM, zador.blood.stained said: Regarding suspend/resume and battery issues on legacy, I would prefer to have ARISC firmware sources and toolchain, otherwise I'm not sure how much can be fixed and improved I have not heard back yet from TL regarding XPowers looking into the issue with the battery charger, and I pretty much would like to see the ARISC code by now since working around that black box is rather frustrating. For now I changed my UPower settings to shutdown at 4% and the default action to 'poweroff' instead of 'hibernate' to avoid issues... 1 Link to comment Share on other sites More sharing options...
pfeerick Posted May 30, 2017 Share Posted May 30, 2017 2 hours ago, zador.blood.stained said: Quick update: no support bmp picture without bpix 24 or 32 Since you're looking at the BMP stuff... any pointers or a link to some docs explaining what command (maybe a imagemagick convert cmd?) I should use to create/convert a compatible BMP for uboot? Either I fed it the wrong format, or ... oh wait, you just committed a change that explains part of it... the paths being wrong for the charge related BMPs anyway. I tried using the bootlogo.bmp from tkaiser's commit, and shoved it into the root of the microSD, but it still didn't like me... I think it said 'not a BMP' or words to that effect... so I'll look again in the morning... I gave up it for the night once I decided to give up and just use the commit BMP and that didn't work for me. And yes, have to look into it further but there is definitely something in the DTS that is causing it... ayufan pointed out one promising line... the lcd_clock, but have to investigate further... Link to comment Share on other sites More sharing options...
tkaiser Posted May 30, 2017 Author Share Posted May 30, 2017 36 minutes ago, pfeerick said: I tried using the bootlogo.bmp from tkaiser's commit, and shoved it into the root of the microSD, but it still didn't like me... You need latest u-boot with @zador.blood.stained's patches: linux-u-boot-pinebook-a64_5.27_arm64.deb.gz Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 30, 2017 Share Posted May 30, 2017 1 hour ago, pfeerick said: And yes, have to look into it further but there is definitely something in the DTS that is causing it... ayufan pointed out one promising line... the lcd_clock, but have to investigate further... At least on 11" setting lcd_dclk_freq = <0x4D>; helps with tearing Link to comment Share on other sites More sharing options...
pfeerick Posted May 31, 2017 Share Posted May 31, 2017 14 hours ago, tkaiser said: You need latest u-boot with @zador.blood.stained's patches: linux-u-boot-pinebook-a64_5.27_arm64.deb.gz Drats... was hoping I'd have those patches already as I was using the nightly from... maybe a week ago? Anyway... I'll run a self-build of the current master in a few minutes and see what it's like. @zador.blood.stained: Edit: One remaining question... I get the boot logo now, but it vanishes as soon as the kernel starts up... normal? and rest doesn't apply Did you check the display settings by any chance? Does that one line also influence the screen refresh rate? I know Luke and I keep harping on about that... but it seems to be a common factor so far... screen refresh rate drops from 60hz to 56hz, funky bottom line of pixels (green or line of red blue green depending on how close you look) goes away, and tearing isn't so obvious on the 11" with horizontal movement of objects on the screen. Link to comment Share on other sites More sharing options...
pfeerick Posted May 31, 2017 Share Posted May 31, 2017 Ok, I can also confirm on my 11" pinebook that changing reduces the tearing and gets rid of the bottom row of dots... it isn't interlaced like it was before, but I think it is still there a bit, but that may be a artefact of XFCE not liking window contents being shown when dragged (easiest way to spot) and not knowing how much we can push the lcd_dclk_freq without something going pop. Interestingly enough the reported screen refresh rate jumps from 60hz to 64 hz. Changing the lcd_ht and lcd_vt then drops it back to 56hz like we usually see on ayufans mate images 2180c2249 < lcd_dclk_freq = <0x48>; longsleep --- > lcd_dclk_freq = <0x4d>; ayufan 2187c2256 < lcd_ht = <0x5dc>; longsleep --- > lcd_ht = <0x640>; ayufan 2190c2259 < lcd_vt = <0x320>; longsleep --- > lcd_vt = <0x35c>; ayufan 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 31, 2017 Share Posted May 31, 2017 4 hours ago, pfeerick said: I can also confirm on my 11" pinebook that changing reduces the tearing and gets rid of the bottom row of dots... OK, so we need to test these values on 14" and if it works fine then this can be considered as fixed. 1 Link to comment Share on other sites More sharing options...
tkaiser Posted May 31, 2017 Author Share Posted May 31, 2017 28 minutes ago, zador.blood.stained said: we need to test these values on 14" and if it works fine then this can be considered as fixed. Tested without issues on 14" Pinebook, PR merged already. Do we need a patch for the same set of changes for u-boot too? 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted May 31, 2017 Share Posted May 31, 2017 2 minutes ago, tkaiser said: Do we need a patch for the same set of changes for u-boot too? Looks like u-boot may use this value, so we can change the DT there too just for the consistency, even though static boot logo should not expose any tearing issues. 1 Link to comment Share on other sites More sharing options...
pfeerick Posted May 31, 2017 Share Posted May 31, 2017 Thanks tkaiser. I'll leave the u-boot patch to you guys (I'm guessing zador?)... I have absolutely no idea where to start on that one... other than guessing that a diff patch needs to go in https://github.com/armbian/build/tree/master/patch/u-boot/u-boot-pine64-default ?? But a diff of what... I'll wait for the commit and work it out then Two things I noticed in the latest build: I get the boot logo now from uboot, but it vanishes as soon as the kernel starts up... or is that expected? The LCD brightness doesn't seem to be able to be adjusted via the power management applet in XFCE. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 Regarding backlight control issues: Jun 06 15:41:31 pinebook pkexec[3562]: zador: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/] [COMMAND=/usr/sbin/xfpm-power-backlight-helper --set-brightness 51] 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 No idea why defaults are there as they are, but brightness is controllable after editing /usr/share/polkit-1/actions/org.xfce.power.policy, so we should add an override for this file somewhere (in /etc?) Edit: fixed 1 Link to comment Share on other sites More sharing options...
Igor Posted June 6, 2017 Share Posted June 6, 2017 "no action" when lid is closed might be related to this? After this mod "screen off" function works, while suspend is no go. Also it does not differentiate when on battery or AC. Brightness can be adjusted manually now, but not by power condition BAT/AC. I guess this power management needs some extra touch Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 7 minutes ago, Igor said: "no action" when lid is closed might be related to this? After this mod "screen off" function works, while suspend is no go. Also it does not differentiate when on battery or AC. Brightness can be adjusted manually now, but not by power condition BAT/AC. I guess this power management needs some extra touch As I said, I personally won't touch suspend/resume at all (on the legacy kernel) unless ARISC firmware sources are provided, but I'll try to fix other issues if I can. Lid switch works in the kernel (there is an input device that sends events on lid open/close), so this just needs propagation to the power management suftware (upower, systemd-logind, ...) 1 Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 For the sleep issue - maybe this should be the first possible candidate to investigate (xfce4-power-manager:1646): xfce4-power-manager-WARNING **: Unable to inhibit systemd sleep: Permission denied Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 In order to fix suspend on closing the lid in XFCE power manager settings on "Security" tab both locking options should be disabled (since Light Locker is not installed by default), or we should install and test light-locker (though it depends on plymouth...). Link to comment Share on other sites More sharing options...
Igor Posted June 6, 2017 Share Posted June 6, 2017 I would prefer to go with no locker - its kind of pointless to lock console if we dont use display manager ... if i understand this properly?Wrote on mobile Link to comment Share on other sites More sharing options...
zador.blood.stained Posted June 6, 2017 Share Posted June 6, 2017 21 minutes ago, Igor said: I would prefer to go with no locker - its kind of pointless to lock console if we dont use display manager ... if i understand this properly? Yes, no locker for now is the way to go, though Pinebook is exactly a kind of device which may benefit from password protection in login manager and locking support in the future. Link to comment Share on other sites More sharing options...
Igor Posted July 1, 2017 Share Posted July 1, 2017 I was using Pinebook for a week and it's performing ... good as a light browsing and remote terminal console work - any objections to move it from WIP section? Any idea why audio stopped to work? IIRC we fixed that. Link to comment Share on other sites More sharing options...
zador.blood.stained Posted July 1, 2017 Share Posted July 1, 2017 12 minutes ago, Igor said: Any idea why audio stopped to work? IIRC we fixed that. All audio or only headphones? Maybe mixer controls were changed upstream? Link to comment Share on other sites More sharing options...
Igor Posted July 1, 2017 Share Posted July 1, 2017 I haven't try headphones yet ... but speakers are off. I am using previous build with upgrade. Link to comment Share on other sites More sharing options...
Recommended Posts