WIP: move Linux frame buffer support to base system #342
+245
−346
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It should be drawn with background rather than foreground color. Sponsored by: Future Crew LLC
used by color splash screens. Sponsored by: Future Crew LLC
In that case vt_drmfb_bitblt_bitmap truncates bitmap width to not cross the border and passes truncated width to cfb_imageblit that results into calculation of wrong line offsets in source bitmap. To see that move mouse pointer to right display edge and slightly touch it. To fix the issue pass both original and truncated width to cfb_imageblit and use former to calculate line offsets and latter to limit width of picture. Sponsored by: Future Crew LLC
With replacement of muls and divs with adds and shifts Sponsored by: Future Crew LLC
Generic framebufer driver is a lower layer than drm framebufer. It should not depend on later. The only usage of passing `struct drm_fb_helper` to vt_drmfb was using it as a container of reference to parent BSD device. Pass device directly from drm to vt_drmfb to not depend on drm. Sponsored by: Future Crew LLC
as vt_drmfb is the only user of skip_ddb. Keep skip_ddb sysctl declarations in drm as they are children of drm sysctl nodes. Sponsored by: Future Crew LLC
support code to consolidate it in one place. This done with adding of FreeBSD-specific fields to drm_driver structure to pass aperture parametrs from drm drivers to framebufer support code. Also remove struct apertures_struct from fb_info to follow upstream. Sponsored by: Future Crew LLC
Remove references to now unused headers, functions and kernel modules. Sponsored by: Future Crew LLC
drm_device destructor is called when pci_device reference count becomes zero. pci_device destructor is called when drm_device reference count becomes zero. As both of them decreases respective counters, noone can reach zero and run destructor that results in armed amdgpu timers after kldunload of amdgpu.ko with following panic. To workaround the panic do not take extra reference in drm codeto break circular dependency. This allows amdgpu.ko to be kldunloaded without system crash. Sponsored by: Future Crew LLC
Sponsored by: Future Crew LLC
Sponsored by: Future Crew LLC
Sponsored by: Future Crew LLC
Would be good to also indicate why they should be in the base system |
|
We a going to make drm.ko to be a part of base system |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On Linux, framebuffer code is not a part of drm and can be used with non-drm drivers.
The aim is to move linux_fb.c vt_drmfb.c to linuxkpi_video module and import to base system after than.
The changes clashes with ongoing drm-kmod 6.xx import doing by @dumbbell. That should be resolved in future.
Still WIP