3 3
tkaiser

Quick Pinebook Preview / Review

Recommended Posts

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)?

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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: armbian-dark-1365_767.png (added some noise to compensate for TN panel crappiness)

 

 

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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...

Share this post


Link to post
Share on other sites
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... 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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]

 

Share this post


Link to post
Share on other sites

"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 :)

Share this post


Link to post
Share on other sites
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, ...)

Share this post


Link to post
Share on other sites

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...).

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
3 3