Guido Günther @agx@librem.one

@tromino @vancha @purism i'm using it on the desktop but there's surely room for improvements so patches in that area are very welcome.

@vancha @purism Uploading phoc/phosh to #debian is on my todo list but i need to update wlroots there first. it will then tickle down to everything Debian based and i've heard rumors of @phosh comint to rawhide.

phosh 0.1.4 is out: https://source.puri.sm/Librem5/phosh/-/tags/v0.1.4

Mostly to fix the pureos amber build but it also fixes window titles in the overview.

#phosh #librem5 @purism #gnomeonmobile #gtk

blank on power button press coming to to the Librem 5 and it's devkit. This is on linux-next + nwl and mxsfb patches and some not yet merged phoc/wlroots patches:

#phosh #librem5

phosh 0.1.3 is out https://source.puri.sm/Librem5/phosh/-/tags/v0.1.3

Most notable change is that favorites are now editable via long press (contributed by Zander Brown). Thanks to everyone who contributed to this release.

#phosh #librem5 @purism #gnomeonmobile #gtk

Tagged #phosh 0.1.2 https://source.puri.sm/Librem5/phosh/-/tags/v0.1.2

which can now be run from display managers like gdm.

#librem5 #gnomeonmobile

Tagged #phosh 0.1.1 - mostly bug fixes this time around: https://source.puri.sm/Librem5/phosh/-/tags/v0.1.1

#librem5 #gnomeonmobile

First bits of fixes for the #librem5 (it uses another chip to drive the backlight than it's devkit) making it mainline already: https://lore.kernel.org/linux-leds/ba610ed3-19b7-3e10-7032-453e0cb05704@gmail.com/

#linux #kernel #librem5 @purism

Released #phosh 0.1.0

https://source.puri.sm/Librem5/phosh/-/tags/v0.1.0

since lots of improvements piled up already, thanks everyone!

#librem5 @purism

simplistic tiling in phosh's compositor

#phosh #librem5 @purism

@purism 's contributions to #linux 5.3 https://puri.sm/posts/purism-linux-5-3/ - there's more to come for 5.4 and 5.5.

@mntmn nice, so what was it?

@mntmn nice, the bridge should be attached by this https://source.puri.sm/guido.gunther/linux-imx8/blob/forward-upstream/next-20190823/mxsfb+nwl/v5/drivers/gpu/drm/bridge/nwl-dsi/nwl-drv.c#L226

@mntmn the sn64dsi86 wants your edp panel as output again (edp_panel_in) - i so far describe the chain only up to that. so its mxsfb -> nwl (drm bridge) -> ts65dsi86 (drm bridge) -> edp (drm panel). see ti_sn_bridge_probe. so your edp panel needs a panel entry within the ts65dsi86's dt node similar to what we do for our dsi panel within the nwl's bridge node: https://source.puri.sm/guido.gunther/linux-imx8/blob/imx8-5.x-drm/arch/arm64/boot/dts/freescale/imx8mq-librem5-devkit.dts#L849 - just a guess since i've not used the ts65dsi86.

@mntmn mxsfb used the lcdif interface instead of dcss which is way simpler and has (with robert's patches that i pulled into my tree) mainline support which dcss hasn't.

@mntmn it allows the mipi dsi host controller to use the iomuxc_gpr as mux controller since it needs to toggle between dcss and mxsfb input.