•   
  • 1
  • 24
  • 25
  • 26
  • 27
  • 28(current)
Headless Kodi
(2018-07-09, 09:56)a1rwulf Wrote:
(2018-07-06, 14:16)Gomez Wrote:
(2018-06-30, 08:00)a1rwulf Wrote:  However it takes a different approach.
My patch renders to an off screen rendernode instead of not creating a gui at all and is tied to linux gbm.  
Great to see people are working on this. I dont understand the use case. Are you running kodi in a headless server? Docker? Whats linux gbm? Some links could be enough for me.  
 Linux GBM is kodi directly talking to the kernel graphics stack via drm/kms (no X server).
My use case is using kodi as musicplayer (analog audio) and control it via kore.
But your use cases would work as well if you have an intel gpu. 
 Does this approach have the benefits of better resource usage?
[Image: addon-TheMealDB-blue.svg] [Image: skin-EstuaryATF-green.svg]
Reply
I don't know the technical details of the code, but I suspect the main benefit of what a1rwulf has done is better for stability as Kodi is built around having an active display device on when using Kodi and from what I understand what this does is fool Kodi into thinking there is still a real display device connected when headless or the connected display is off, the headless patch discussed here is a more quick and dirty hack which is why it's never made it into the code.
Reply
(2018-07-09, 13:10)jjd-uk Wrote: I don't know the technical details of the code, but I suspect the main benefit of what a1rwulf has done is better for stability as Kodi is built around having an active display device on when using Kodi and from what I understand what this does is fool Kodi into thinking there is still a real display device connected when headless or the connected display is off, the headless patch discussed here is a more quick and dirty hack which is why it's never made it into the code.

My approach renders to an off screen target.
It's still a workaround but fits into the gbm code architecture.
Imho it's an "OK" solution (at least for my use case) until we have proper headless support.
Reply
fyi - my PR has been merged.
Reply
Fantastic How do we test?

What improvements can we expect when running headless?
[Image: addon-TheMealDB-blue.svg] [Image: skin-EstuaryATF-green.svg]
Reply
(2018-07-16, 14:00)docwra Wrote: Fantastic How do we test?

What improvements can we expect when running headless?
As said I did this to serve my use case:
Using kodi as music player by controlling via kore.
From a quick glance it looks like the headless patches here don't create a GUI at all.
So I'd expect my implementation is more expensive as there's normal rendering done to a render node.
However it fit's good into the gbm architecture has low impact and therefore is already upstreamed.
It's close to running kodi with your screen off ;-)

You'll need to build from source currently:
https://github.com/xbmc/xbmc/blob/master...E.Linux.md
Reply
(2018-07-16, 21:25)a1rwulf Wrote:
(2018-07-16, 14:00)docwra Wrote: Fantastic How do we test?

What improvements can we expect when running headless?
It's close to running kodi with your screen off ;-) 
I also run a headless Raspberry Pi + Justboom AMP hat for music. But it doesn't have a screen at all, I just connect over JSON with no HDMI cable or video output connected.

Am I right in thinking there is no advantage to this patch, or am I missing something?

Ideally I would like a low resource Kodi setup for my PI that has some kind of boot option or switch to go headless (i like to plug it in sometimes to upgrade or change options).
[Image: addon-TheMealDB-blue.svg] [Image: skin-EstuaryATF-green.svg]
Reply
In this case I think you'll need to wait until our dependencies are properly untangled and we can officially make gui optional.
Reply
  •   
  • 1
  • 24
  • 25
  • 26
  • 27
  • 28(current)
 
Thread Rating:
  • 5 Vote(s) - 5 Average



Logout Mark Read Team Forum Stats Members Help
Headless Kodi55