We only set changes on the main protocol screen as, for example
in RRSetChanged() and RRTellChanged(), therefore we should follow
the same logic when reporting that an output changed in
RROutputChanged().
This means that RRTellChanged() will then update the relevant
timestamps also when events com
We only set changes on the main protocol screen as, for example
in RRSetChanged() and RRTellChanged(), therefore we should follow
the same logic when reporting that an output changed in
RROutputChanged().
This means that RRTellChanged() will then update the relevant
timestamps also when events com
We only set changes on the main protocol screen as, for example
in RRSetChanged() and RRTellChanged(), therefore we should follow
the same logic when reporting that an output changed in
RROutputChanged().
This means that RRTellChanged() will then update the relevant
timestamps also when events com
On 14.01.2014 00:37, Alberto Milone wrote:
> On 16/12/13 09:52, Alberto Milone wrote:
>> On 12/12/13 10:00, Alberto Milone wrote:
>>> We only set changes on the main protocol screen as, for example
>>> in RRSetChanged() and RRTellChanged(), therefore we should follow
>>> the same logic when reporti
On 08/12/13 12:08, Alberto Milone wrote:
> We only set changes on the main protocol screen as, for example
> in RRSetChanged() and RRTellChanged(), therefore we should follow
> the same logic when reporting that an output changed in
> RROutputChanged().
>
> This means that RRTellChanged() will the
On Sun, Dec 8, 2013 at 9:08 PM, Alberto Milone
wrote:
> We only set changes on the main protocol screen as, for example
> in RRSetChanged() and RRTellChanged(), therefore we should follow
> the same logic when reporting that an output changed in
> RROutputChanged().
>
> This means that RRTellChang
On 09/12/13 03:53, Dave Airlie wrote:
> On Sun, Dec 8, 2013 at 9:08 PM, Alberto Milone
> wrote:
>> We only set changes on the main protocol screen as, for example
>> in RRSetChanged() and RRTellChanged(), therefore we should follow
>> the same logic when reporting that an output changed in
>> RROu
Alberto Milone writes:
> +if (pScreen->isGPU) {
> +master = pScreen->current_master;
> +if (!master)
> +return;
> +mastersp = rrGetScrPriv(master);
> }
> +else {
> +master = pScreen;
> +mastersp = pScrPriv;
> +}
> +
> +RRSet
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/12/13 19:51, Keith Packard wrote:
> Alberto Milone writes:
>
>> +if (pScreen->isGPU) { +master =
>> pScreen->current_master; +if (!master) + return; +
>> mastersp = rrGetScrPriv(master); } +else { + master =
>> pScreen;
Alberto Milone writes:
> I thought about it but I also thought that RRSetChanged() would get
> master anyway.
>
> The potential benefit of passing the gpu screen is that if we ever
> wanted to do something on the gpu screen in RRSetChanged() (other than
> setting screen->changed to TRUE) before g
On 12/12/13 10:00, Alberto Milone wrote:
> We only set changes on the main protocol screen as, for example
> in RRSetChanged() and RRTellChanged(), therefore we should follow
> the same logic when reporting that an output changed in
> RROutputChanged().
>
> This means that RRTellChanged() will the
On 16/12/13 09:52, Alberto Milone wrote:
> On 12/12/13 10:00, Alberto Milone wrote:
>> We only set changes on the main protocol screen as, for example
>> in RRSetChanged() and RRTellChanged(), therefore we should follow
>> the same logic when reporting that an output changed in
>> RROutputChanged()
12 matches
Mail list logo