1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
- Acceleration
- Blits and solid fill
- XAA and the shadow buffer will not work together, because the
shadow buffer updates in the block handler, so if we got any XAA
calls in between, things would get messed up.
Current plan:
- Add our own damage tracker that produces raw rectangles
- Whenever it fires, submit the copy immediately
- Wrap the necessary ops in such a way that the original
implementation gets called first. The original implementation
will use fb, which will produce damage, which will get
submitted.
If we decide to accelerate a particular operation, first set
a flag that the immediately following damage event should not
result in spice protocol being sent. Ie.,
on_op:
qxl->enable_copying = FALSE
call original;
send acceleration command
qxl->enable_copying = TRUE
Note damage is added before the drawing hits the framebuffer, so
it will have to be stored, then cleared
- in a block handler
- before accelerating
Ie.,
on_op:
clear damage
disable damage reporting
call original (this will generate unreported damage and paint to the shadow)
submit command
enable damage
It may be possible to use the shadow code if we added a
shadowReportNow() that would report any existing
damage. Ie., basically export shadowRedisplay()
1. Get damage added, out of CreateScreenResources
2. Make sure it works
3. Submit copies and disable shadow
4. Delete shadow
5. Wrap some of the ops, or use XAA?
The input we get is:
- First a damage notification: "I am going to draw here"
- Then maybe an exa notification
So the algorithm is.
Maintain a "to_copy" region to be copied into the device
- in damage, if there is anything in to_copy, copy it
- in block handler, if there is anything in to_copy, copy it
- in exa, if we manage to accelerate, delete to_copy.
Unfortunately, for core text, what happens is
- damage is produced for the glyph box
- solid fill is generated
- the glyph is drawn
And the algorithm above means the damage is thrown away.
- Coding style fixes
- Better malloc() implementation
- Take dmalloc() from the windows driver?
- Put blocks in a tree?
- Submit cursor images
- Find out why it picks 8x6 rather than a reasonable mode
- Possibly has to do with the timings it reports. RandR only
allows 8x6 and 6x4.
- Only compile mmtest if glib is installed
Or maybe just get rid of mmtest.c
-=-=-=-=-
Done:
Question:
- Note: when we set a mode, all allocated memory should be considered
released.
- What is the "vram" PCI range used for?
As I read the Windows driver, it can be mapped with the ioctl
VIDEO_MAP_VIDEO_MEMORY. In driver.c it is mapped as pdev->fb, but
it is then never used for anything as far as I can tell.
Does Windows itself use that ioctl, and if so, for what. The area
is only 32K in size so it can't really be used for any realistic
bitmaps.
It's a required ioctl. I believe it's needed for DGA-like things.
I have no idea how the Windows driver manages syncing for that,
but I think we can safely ignore it. [ajax]
- Hook up randr if it isn't already
- Garbage collection
- Before every allocation?
- When we run out of memory?
- Whenever we overflow some fixed pool?
- Get rid of qxl_mem.h header; just use qxl.h
- Split out ring code into qxl_ring.c
- Don't keep the maps around that are just used in preinit
(Is there any real reason to not just do the CheckDevice in ScreenInit?)
|
