This field hasn't been actually used, so no need to keep it any longer.
Fixes: 60f14d60f6
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The symbol isn't set anywhere, and git history didn't show anything
were it ever had been set, thus no need to keep this.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call KdCloseScreen() from
KdXVCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to wrap CloseScreen proc vector, we can call fbCloseScreen() from
KdCloseScreen() directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->ResizeWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->CopyWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both engines, GDI as well as DirectDraw, using the same screen init finish function,
so no need to keep indirection via per-engine callback pointer.
The winFinishScreenInitFB() can also be made static now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need for complicated wrapping/unwrapping: it's always just
miCreateResources() anyway - so we can call it directly.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The private struct is pretty small and it needs to be allocated anyways,
so save an extra allocation by directly embedding it.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external.
(BTW, those defines are only used within xf86-video-fbdev, so they maybe
could be moved over there.)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used anywhere, neither internal nor external (drivers), so no need
to keep it any longer.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any external consumers, only within the same source file,
so can become static.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No external users, so no need to keep them exported.
(note that xf86-video-intel has it's own copies of them)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Those aliases haven't been used (outside fb core itself), since XAA removal
back 17 years ago, no no need to carry them in public interface any longer.
See: 703a9645f3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Hasn't been used since 15 years so, probably should was forgotten to clean up.
See: bbbf795e6b
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>