Sign up here and you can log into the forum!

DMAOSD replacement

Have a question about devices internals, memory layout, reverse engineering, etc---This is the place for anything so technical that it would cause a n00b's head to 'splode

Re: DMAOSD replacement   

Postby b-rad.cc » Tue May 25, 2010 3:43 pm

kexec has been around and worked since 8635 days. The problem is it was never stable enough to do any good.
PM's are for private matters only, please post public matters on the forum to help others who might have the same issue.
:mrgreen:
User avatar
b-rad.cc
WDLXTV Team
 
Posts: 3003
Joined: Sat Apr 03, 2010 9:35 am
Location: New York

Re: DMAOSD replacement   

Postby macrule2001 » Mon Nov 08, 2010 5:09 pm

I thought it's about time this topic got back to the top.

I managed to compile microwindows in two parts:
  • Part 1 is a regular libnano-X that clients can link against. This has no dependency on any unknown libraries, and is very straightforward to make and use.
  • Part 2 is a modified libnano-X that contains only the server parts. And I mean really only the parts dealing with accepting and handling client connections. It doesn't need to have anything else in it, because conveniently dmaosd contains symbols for all the Gr* functions that do the legwork.
Now what I do is preload this modified library when running dmaosd. The preload-library overwrites the GrOpen() function to do everything that the "real" dmaosd GrOpen() function does, but then never returns control to dmaosd. Instead it runs the server accept loop.

This way I managed to get simple things like polydemo to work, so it's a working proof of concept that we can take control of the screen without having to reverse-engineer nasty bits or get into trouble about half-legal SDKs.

It's quite late now, so I will leave it at this short "heads up" for the moment. I will provide the modified microwindows code soon and would be happy for takers to join into this.
macrule2001
Developer
 
Posts: 22
Joined: Mon Nov 08, 2010 4:56 pm

Re: DMAOSD replacement   

Postby RMerlin » Tue Nov 09, 2010 7:07 am

Nice work. You're aware however that WD has ditched nanox in the 1.03/2.0 firmware, and replaced it with directfb? :)
WDLXTV Webend maintainer. Visit http://www.lostrealm.ca/wdlxtv to see my other WDLXTV projects.
If you like my work, please consider donating.
User avatar
RMerlin
WDLXTV Team
 
Posts: 3236
Joined: Sat Jun 26, 2010 9:25 am
Location: Montreal, Canada

Re: DMAOSD replacement   

Postby macrule2001 » Tue Nov 09, 2010 7:33 am

RMerlin wrote:You're aware however that WD has ditched nanox in the 1.03/2.0 firmware, and replaced it with directfb? :)


Am now! Thanks for pointing it out.

So has anyone tried working with directfb yet?
macrule2001
Developer
 
Posts: 22
Joined: Mon Nov 08, 2010 4:56 pm

Re: DMAOSD replacement   

Postby macrule2001 » Tue Nov 09, 2010 2:56 pm

Right. I have tried the 1.03.39 and compiled the DirectFB tools for it, and the output I get from dfbinfo is this:
Code: Select all
(*) DirectFB/Config: Active DTV standard hdtv60
(*) DirectFB/Config: Active DTV signal 720p
(*) DirectFB/Config: Active DTV connector hdmi
(*) DirectFB/Config: Active Component standard hdtv60
(*) DirectFB/Config: Active Component signal 720p
(*) DirectFB/Config: Active DTV connector ycrcb
(*) DirectFB/Config: Active Analog standard ntsc
(*) DirectFB/Config: Active Analog signal ntsc
(*) DirectFB/Config: Active Analog connector cvbs
(!) DirectFB/Config: No driver option file specified!
(#) DirectFBError [DirectFBInit() failed]: Invalid argument!


I'm quite ok with Mac and BSD, but not with linux, so maybe I'm missing something important here: but isn't dfb useless if there is no /dev/fb device made available?
macrule2001
Developer
 
Posts: 22
Joined: Mon Nov 08, 2010 4:56 pm

Previous

Return to WDTV Live

Who is online

Users browsing this forum: No registered users and 2 guests