Re: [xine-devel] potential problem: choice of video-out - fallback to XShm

[Heiko S. <hsc...@ft...>]

Hi Miguel, everyone,

> > the second xine instance already runs on XShm and when closing those
> > instances in the 'wrong' order, the configfile will be set to XShm - and
> > the casual user will never get Xv back.
[...]
> the same goes for the audio driver. sometimes oss can't be opened
> because of arts and it saves that on config. of course, arts sucks badly
> (it's a magic xine do to keep almost perfect sync with arts).

i didn't think of audio, since i didn't personally have that problem so
far, but you're of course right.

> > i think the general behaviour of xine's config options is not quite
> > perfect yet and this is one obvious example of where the behaviour is not
> > matching what i would consider 'reasonable' - and what casual users should
> > expect. as i don't really have a coherent idea of how things should be
> > done, i certainly won't do anything about that now. but maybe someone will
> > have an idea :)
>
> what about saving "auto" in config file? xine-lib would never change
> this setting (not even when user passed the -V option).

hmm, somehow i assumed that the video/audio.driver is set to 'auto'
initially. as far as i see it, this video.driver setting is handled by the
ui. looking at xine-ui, i see that video.driver gets set to auto as a
default, and is then updated to some specific driver after detection has
succeeded.

maybe just leaving out this update would be the right thing. daniel ? any
opinion on this !?

anyway, seems this would be a ui-specific design decision... hum.
i don't get why gxine could ever have fallen back to XShm then...

> to have the default driver changed, user would have to explicity set it
> in config menu. even this way, general fallback mechanism would apply if
> specified driver fails.
>
> does it sounds reasonable?

very, yes :)
even though i'm not quite clear on how that would be implemented.

> > on the other hand i could claim that the memcpy-routine detection should
> > always happen at startup time (the user could share his home directory
> > between various machines which have drastically different memcpy
> > performance) - but this would of course delay startup unacceptably. so we
> > probably want to keep the detected memcpy routine.
>
> the way i coded that detection routine it should run again if some cpu
> capabilities change in a incompatible way.
>
> but keep in mind that the overall impact on xine architecture is fairly
> small. we don't use memcpy that often.

yes, i'm not suggesting to change the behaviour of memcpy detection.
i was just trying to make the point that even though video.driver
detection and memcpy method detection are technically very similar (some
probing is done, and then a decision is made that should in theory be
permanent for a given system) they must probably be handled differently.
which is not really nice from a design point-of-view.

...i still have this feeling that the config-system could use some general
restructuring - but every time i start thinking about it more seriously,
my head spins :)

Heiko