DirectFB - Home of the pragmatist Roadmap


[directfb-users] No rule to make target `hw/directfb/libdirectfb.a`
Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[directfb-users] No rule to make target `hw/directfb/libdirectfb.a`



Hi, when I tried to compile Xdirectfb, it ended with

no rule to make target `hw/directfb/libdirectfb.a` needed by `XDirectFB`

what could this be?

I have DirectFB 0.9.20
DFBTerm is working
I got the cvs version of XFree86 today



On Thu, 5 Feb 2004, Denis Oliver Kropp wrote:

> Quoting Colin Paton:
> > Hi,
> >
> > I've had another play around with the CLE266 mpeg stuff (unlike the other
> > night when I was trying to rush things and got it all wrong - D'oh. Ignore
> > my previous posting about the HQV surface. More haste less speed....)
> >
> > Further to the suggestion from Ville Syrjälä (Thanks for that) I decided to
> > hack the driver to see if it could do YV12 blits as three separate Y,U,V
> > blits. My results are encouraging - it can!
> >
> > It also seems to work quite well - I'm now getting about 6-8% CPU usage
> > playing a video at 50fps, which is pretty good.
>
> ;)
>
> > I've created some proof of concept code. The uc_blit function has been
> > altered so that it does 3 blits, but it also sets up the source and
> > destination parameters (uc_set_destination and uc_set_source_2d now set some
> > global variables which are referenced by uc_blit).
>
> I hope the "global variables" are stored in the device data struct
> UcDeviceData, which resides in shared memory.
>
> > The code works but is rather ugly. The problem stems from the fact that the
> > source and destination blit offsets etc are considered as part of the state
> > of the card, whereas I now alter them for each blit. This mechanism is a
> > good optimisation for 'normal' graphics drawing.
>
> Which optimization?
>
> > Is it possible to save register contents? One possible mechanism to
> > integrate this more nicely into DirectFB is to add a uc_planar_blit call in
> > addition to uc_blit, and set the function pointer to uc_blit or
> > uc_planar_blit depending on the surface format.
>
> Yes, that would also make the Matrox driver a bit more readable.
>
> > In addition, I've added 'YV12' into uc_has_dst_format, which I believe might
> > conceivably break functions that try to do a non-blit operation to a YV12
> > surface.
>
> You can check for the special case in uc_check_state().
>
> --
> Best regards,
>   Denis Oliver Kropp
>
> .------------------------------------------.
> | DirectFB - Hardware accelerated graphics |
> | http://www.directfb.org/                 |
> "------------------------------------------"
>
>                             Convergence GmbH
>
>
> --
> Info:  To unsubscribe send a mail to ecartis@directfb.org with
> "unsubscribe directfb-dev" as subject.
>




--
Info: To unsubscribe send a mail to ecartis@directfb.org with
"unsubscribe directfb-users" as subject.



Home | Main Index | Thread Index


directfb.org / Development / Old Archives