Date: Fri, 22 Dec 2006 14:01:11 +0100 From: usleepless@gmail.com To: "John-Mark Gurney" <gurney_j@resnet.uoregon.edu>, usleepless@gmail.com, "Greg 'groggy' Lehey" <grog@freebsd.org>, "Stephen Hocking" <stephen.hocking@gmail.com>, multimedia@freebsd.org Subject: Re: MythTV and PVR500 (was: Possible FreeBSD port?) Message-ID: <c39ec84c0612220501i1d164c3cq1580cf2b005dd6ba@mail.gmail.com> In-Reply-To: <20061222014304.GB4982@funkthat.com> References: <6300771b0612181401i72e7cc58ta08e12de8d68d4d0@mail.gmail.com> <6300771b0612181533m6ece3f38p379c78a75912d10d@mail.gmail.com> <6300771b0612181534h3158342aw554869660fc707ea@mail.gmail.com> <20061218234041.GU4364@wantadilla.lemis.com> <c39ec84c0612190937u572ff6bco28606f54645275a5@mail.gmail.com> <20061219224005.GC4364@wantadilla.lemis.com> <c39ec84c0612191509w6a5ccf10iedb640bb8dacef1c@mail.gmail.com> <20061220000049.GF4364@wantadilla.lemis.com> <c39ec84c0612201340n5644c218ma6d427b3334f2d01@mail.gmail.com> <20061222014304.GB4982@funkthat.com>
index | next in thread | previous in thread | raw e-mail
John, List, On 12/22/06, John-Mark Gurney <gurney_j@resnet.uoregon.edu> wrote: > usleepless@gmail.com wrote this message on Wed, Dec 20, 2006 at 22:40 +0100: > > because i am still running on a 4.11 server, the mythbackend needed to > > run on 4.11. i soon discovered that mythtv had strange ipc, so i > > compiled it against linux-threads ( had to rebuild QT with > > linux-threads as well ). i remember it helped a little, but not > > enough. > > > > i stumbled upon all the busy-wait-loops: > > > > " > > while(!condition) > > usleep(50); > > " > > > > this is probably the reason why i needed linux-threads. but there is a > > catch: linux-usleep guarantees a context-switch, while freebsd doesn't > > ( didn't ? ). > > > > my first solution was to redefine usleep in mythcontext.h, to force a > > context-switch. this produced a working mythtv-install. later on, i > > removed all busy-wait-loops because they are just plain stupid. > > Why not use sched_yield(2)? I forget if it's in 4.x, but I'm pretty > sure just yield is in 4.x... That will force a context switch... in the end i did. i tried a couple of different redefines of usleep combined with sched_yield, pthread_yield, the qt-variant etc. i don't remember exactly which i used in the end, but i can look it up if it becomes relevant. while redefining usleep, i started logging all usleep's ( which are also context-switches ). the amount of usleeps was so mind-boggling i decided to try to get rid of most of them. some i replaced with QWaitConditions, other i eliminated by changing a module to an event-driven model instead of .... welll.... i don't know how to call it. microprocessor-c-style might be the closest i can think of ( think PIC/atmel style c-code ) anyways, i am very happy that a discussion is going on about fbsd-mm, mythtv and how to get on par mm-wise with other systems. i hope things "spin up" in the sense that if we have a "just works" mythtv-port, someone somewhere will decide "now is the time for adding dvb or whatever". although i am sticking to my own 0.18-fixes-postgresql-usleepless-mythtv for the moment, in the end the best thing for me would be to run the standard mythtv-port tool and participate in the normal upgrade cycle. but because of personal wackyness i refuse to install mysql. i am willing to spend some time on this, for example with my experience with compiling v4l2 stuff for freebsd, i would be happy to extend the bktr driver to do the same. but it would like to be paired up with a buddy who is actually using bktr-cards who can test and debug a little as well. any takers? for example, we could define relatively small goals: make the bktr-driver run with mplayer through v4l2 or make the bktr-driver run with a linux-tv-viewing app which is currently not supported ( kdetv? ). just implement the minimal subset to make it work, and from there take on another app and eventually mythtv. let's feed this thread, keep it alive. regards, usleephome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c39ec84c0612220501i1d164c3cq1580cf2b005dd6ba>