Login at Kodi Home

kemonine96 · 2013-01-30, 05:51

Good to know. TheUni gave me a couple ideas on what to do for the render stuff last night on IRC. I am working on integrating the bits now.

The big trick is figuring out what events are fired (from what I can tell none in the native activity) when the bar shows/hides so I can make sure I can poke the renderer at the right time and get it to change the resolution.

davilla · 2013-01-30, 05:57

the important thing is that you can go into video setting (OSD) and diddle with zoom and pixel ratio to 're-adjust' the picture to be correct Smile

That means that with the appropriate correction, life will be good again.

kemonine96 · 2013-01-30, 06:27

At least there is a work around.

My fun discovery of tonight: the action bar showing/hiding doesn't seem to fire the onWindowResized method or any of the other window related on methods that are in CXBMCApp. I now likely have to screw about and setup an OnSystemUIVisibilityChangeListener to get resizing to fire properly.

However, I need the auto-resolution stuff working first. Calling CApplicationMessenger::Get().DestroyDisplay() and CApplicationMessenger::Get().SetupDisplay(); following the hide/show action bar calls is causing seg faults.

davilla · 2013-01-30, 06:59

DestroyDisplay/SetupDisplay is quite rude, specially if you are playing video Smile

All you might need to do is alter some vars in g_graphicsContext.GetViewWindow()

kemonine96 · 2013-01-30, 07:03

(2013-01-30, 06:59)davilla Wrote: DestroyDisplay/SetupDisplay is quite rude, specially if you are playing video All you might need to do is alter some vars in g_graphicsContext.GetViewWindow()

Will try that next. Memphiz said to try calling g_windowing.UpdateResolutions() and call a reset on the render system, I'm currently grepping for how to do the latter part. What does GetViewWindow return (asking to save myself a bit of digging)?

davilla · (This post was last modified: 2013-01-30, 07:51 by davilla.)

Size and position of view window which includes any calibration adjustments. CAMLPlayer uses it to size the video playback correctly since it's rendered on a plane behind GLES. We get a DestRect but need to know the relation of that to how the GUI is shown so we can show it in the right place.

What you might do is log various g_windowing vars while diddling with ODS zoom/pixel ratio, that will show you what is being changed.

kemonine96 · 2013-01-30, 19:23

(2013-01-30, 07:51)davilla Wrote: Size and position of view window which includes any calibration adjustments. CAMLPlayer uses it to size the video playback correctly since it's rendered on a plane behind GLES. We get a DestRect but need to know the relation of that to how the GUI is shown so we can show it in the right place.

What you might do is log various g_windowing vars while diddling with ODS zoom/pixel ratio, that will show you what is being changed.

Thanks for the tips. I'll have a look and see what I can find.

droshi · (This post was last modified: 2013-01-31, 20:33 by droshi.)

Not sure if anyone has found this link yet, but this flag should work:
http://developer.android.com/reference/a...NAVIGATION

At least on Jelly Bean 4.2 it works on the newest version of MX Player:
https://sites.google.com/site/mxvpen/tra...test-build

Also, I believe it should be easy to register XBMC as a "home" or "launcher" window, so that when it's installed it asks if you want to be taken to your launcher or XBMC by default. Useful for those that will just be running XBMC full-time.

manxam · 2013-01-31, 21:36

Droshi, I referenced that in page 2 of this thread and I believe that is what's being used for this. The issue *I believe* is the way that XBMC android draws the screen as it uses a different render mechanism (non-native??) than the likes of MX player etc..

kemonine96 · 2013-01-31, 21:45

(2013-01-31, 20:31)droshi Wrote: Also, I believe it should be easy to register XBMC as a "home" or "launcher" window, so that when it's installed it asks if you want to be taken to your launcher or XBMC by default. Useful for those that will just be running XBMC full-time.

This has likely been discussed elsewhere and, if possible, I would like to keep the thread on topic.

(2013-01-31, 20:31)droshi Wrote: Not sure if anyone has found this link yet, but this flag should work:
http://developer.android.com/reference/a...NAVIGATION

The above code is what I am using, yes. The pull request in the original post details what I am using for show/hide in the code.

(2013-01-31, 21:36)manxam Wrote: Droshi, I referenced that in page 2 of this thread and I believe that is what's being used for this. The issue *I believe* is the way that XBMC android draws the screen as it uses a different render mechanism (non-native??) than the likes of MX player etc..

The issue is whenever the nav bar hides, it shifts the XBMC render down by however many pixes the action bar is on your device. I have been busy lately but davilla, TheUni and Memphiz have provided me some ways to get the render to re-draw with the new resolution now available. My difficulty right now is free time to read through the code and get one of the approaches working.

droshi · 2013-01-31, 23:03

Ah I understand. I can see the problem myself as well. If you launch XBMC and then manually hide the nav bar it does the same where the resolution doesn't change.

Sorry for not reading the whole thread, it was unclear who was working on this and what the current progress was.

Keep up the good work!

davilla · 2013-02-01, 04:16

@droshi, I think the pull request reference in the very first post makes it very clear who is working on this and what is the status of the current progress.

kemonine96 · 2013-02-09, 08:06

@davilla Know of a way to make a set top box's action bar behave like a touch device? I got my hands on a JynxBox HD Mini this week and want to use it for testing the action bar work if possible. I got it to always show the bar, but it refuses to hide it for some reason.

The crazy part is that the mouse click behavior matches my N7: two clicks to pop the osd, but the action bar refuses to hide Sad

Worst case scenario I just found an edge case bug for the future...

CruNcher · (This post was last modified: 2013-02-10, 03:53 by CruNcher.)

i saw some funny things with the nav bar and different player on this Jelly Bean 4.1.1 firmware (RockChip) the most funniest was that after the osd closed the nav bar tried to close too but couldn't and would force trying to close every 1 ms after that but it wouldn't close and come up again try to close come up again and so on (resulting in like a flickering nav bar on the bottom) Wink

Very funny stuff the Nav Bar behaviour from different apps Wink

So far only Archos seems to have it fully under control Smile

and 1 other player i found now that does it also correct Smile

but it really seems there are still maybe even not a handfull of player apps that does handle the nav bar closeing and a real fullscreen mode right Big Grin

(Google Playstore Evaluation) including the top user ones like MX Player and Bs Player which only use the Ghost Interface.

XBMC would be maybe around the 3rd app that does it right, from all those available players and clones Wink

CruNcher · (This post was last modified: 2013-03-03, 21:50 by CruNcher.)

Add RockChips Player to Fullscreen capable